SocketCluster VS Faye

This is basically the principle behind https://socketcluster.io/ scalability; the sharding of channels across available brokers is pseudo-random. It uses a hash function for determinism but the distribution looks essentially random.

I started building something pretty obscure about 14 years ago; https://socketcluster.io/ an open source, WebSocket-based RPC + pub/sub library with a focus on in-order async stream-processing with backpressure monitoring.

It didn't start out like that. Initially, it was just another WebSocket library with a focus on making it easier to scale to multiple processes.

It's kind of mind-bending to me though that it still feels like it's "too early." You'd think that the ability to efficiently process RPCs and pub/sub messages from clients whilst maintaining ordering would be critical... Yet if you look around the industry; callback-based event handlers are still the norm for most application logic and people are still not using queues where they should be. People think of queues as some expensive/bulky system with overhead which requires additional architecture (e.g. RabbitMQ, Kafka, STOMP, NSQ) and always requires exactly-once delivery, they have not tried to make the idea a core part of their application logic. Software today is FULL of race conditions because of this blind-spot. Yet I still cannot communicate my message. It's too difficult to explain the benefits.

I've been advocating for this approach for years. You can't avoid race conditions without using some kind of queueing mechanism and you need backpressure to measure queue capacity. I built this into every aspect of https://socketcluster.io/ - From pub/sub channels, RPCs to event listeners.

It's interesting reading this.

Preventing these kinds of concurrency issues is exactly why I built https://socketcluster.io years ago. Though it solves the problem at the app layer rather than the storage layer.

But not many developers care about these race conditions it seems.

It's not just an issue with SQL but a more general issue with coding.

This is a great example because it shows how concurrent executions can lead to significant issues.

My project https://github.com/socketCluster/socketcluster has been accumulating stars slowly but steadily over 15 years. Now it has over 6k stars but it doesn't seem to mean much nowadays as a metric. It sucks having put in the effort and seeing it get lost in a sea of scams.

Well I built it up in parts and brought the parts together over time. SocketCluster has over 6k stars on GitHub. https://github.com/socketCluster/socketcluster

Saasufy itself isn't open source but I'm planning to sell licenses of the code. SocketCluster is a core component of Saasufy. The goal did evolve slightly; originally, it was to make it easier to build full stack applications. Now it's actually; lets you build entire full stack apps without code. That bigger goal has been achieved. I have some videos linked from the Docs page showing how it works.

https://socketcluster.io/ has had such stream implementation and backpressure management since at least 2019;.

https://github.com/SocketCluster/writable-consumable-stream

The problem with HTTP2 is that the server-push aspect was tacked on top of an existing protocol as an afterthought. Also, because HTTP is a resource transfer protocol, it adds a whole bunch of overheads like request and response headings which aren't always necessary but add to processing time. The primary purpose of HTTP2 was to allow servers to preemptively push files/resources to clients to avoid round-trip latency; to reduce the reliance on script bundles.

WebSockets is a simpler protocol built from the ground up for bidirectional communication. It provides a lot more control over the flow of data as everything passes over a single connection which has a single lifecycle. It makes it a lot easier to manage state and to recover cleanly from a lost connection when you only have one logical connection. It makes it easier to process messages in a specific order and to do serial processing of messages.

I considered the possibility of switching the transport to HTTP2 for https://socketcluster.io/ years ago, but it's a fundamentally more complex protocol which adds unnecessary overheads and introduces new security challenges so it wasn't worth it.

For WebSockets, using SocketCluster (https://socketcluster.io), it's possible to queue up all requests from the same client and then detect and respond to high backpressure spikes (e.g. by disconnecting the client and/or recording the incident).

You can combine different approaches like limiting the number of connections from a single IP within a certain timeframe and also limiting the backpressure.

The ability to measure and respond to extreme backpressure spikes on a per-end-user basis is highly valuable because backpressure in SocketCluster takes into account the processing time of client requests.

A common strategy that spammers use is to identify and invoke the most expensive endpoints in your system.

A lot of people still don't understand the value proposition of being able to process requests from clients in-order. It's also really good at preventing race conditions and makes your environment highly predictable.

Faye WebSocket is a versatile WebSocket implementation derived from the Faye project. Faye is a messaging system that uses the Publish/Subscribe model and the Bayeux protocol. It provides message servers for Node, Ruby, and all major web browsers.

I can find socket.io, faye, deepstream.io , autobahn-js and nchan, centrifugo. Can you also explain why you chose it and if you had troubles with some other solution?