The hidden complexity of scaling WebSockets
composehq.com
The hidden complexity of scaling WebSockets
1–10 of 72 posts
Re: The hidden complexity of scaling WebSockets
#2This is all true, but it also serves to remind us that Rails gives developers so much out of the box, even if you're not aware of it.
ActionCable is Rails' WebSockets wrapper library, and it addresses basically every pain point in the post. However, it does so in a way that all Rails developers are using the same battle-tested solution. There's no need for every project to hack together its own proprietary approach.
Thundering herds, heartbeat monitoring are both covered.
If you need a messaging schema, I strongly recommend that you check out CableReady. It's a powerful library for triggering outcomes on the client. It ships with a large set of operations, but adding custom operations is trivial.
https://cableready.stimulusreflex.com/hello-world/
While both ActionCable and CableReady are Rails libraries, other frameworks would score huge wins if they adopted their client libraries.
Re: The hidden complexity of scaling WebSockets
#3I recall another complication with websockets: IIRC it's with proxy load balancers, like binding a connection to a single connection server, even if the backend connection is using HTTP/2. I probably have the details wrong. I'm sure someone will correct my statement.
Re: The hidden complexity of scaling WebSockets
#4I recall another complication with websockets: IIRC it's with proxy load balancers, like binding a connection to a single connection server, even if the backend connection is using HTTP/2. I probably have the details wrong. I'm sure someone will correct my statement.
Horizontal scaling is certainly a challenge. With traditional load balancers, you don't control which instance your clients get routed to, so you end up needing to use message brokers or stateful routing to ensure message broadcasts work correctly with multiple websocket server instances.
Re: The hidden complexity of scaling WebSockets
#5This is all true, but it also serves to remind us that Rails gives developers so much out of the box, even if you're not aware of it. ActionCable is Rails' WebSockets wrapper library, and it addresses basically every pain point in the post. However, it does so in a way that all Rails developers are using the same battle-tested solution. There's no need for every project to hack together its own proprietary approach.…
Node has similar libraries like Socket.IO too, but it over-abstracts it a bit in my opinion.
Re: The hidden complexity of scaling WebSockets
#6I recall another complication with websockets: IIRC it's with proxy load balancers, like binding a connection to a single connection server, even if the backend connection is using HTTP/2. I probably have the details wrong. I'm sure someone will correct my statement.
I think there is a way to do it, but it likely involves custom headers on the initial connection that the load balancer can read to route to the correct origin server.
I imagine the way it might go is that the client would first send an HTTP request to an endpoint that returns routing instructions, and then use that in the custom headers it sends when initiating the WebSocket connection.
Haven't tried this myself though.
Re: The hidden complexity of scaling WebSockets
#7This is all true, but it also serves to remind us that Rails gives developers so much out of the box, even if you're not aware of it. ActionCable is Rails' WebSockets wrapper library, and it addresses basically every pain point in the post. However, it does so in a way that all Rails developers are using the same battle-tested solution. There's no need for every project to hack together its own proprietary approach.…
Node has similar libraries like Socket.IO too, but it over-abstracts it a bit in my opinion.
I've done my share of building websocket servers from scratch, but when you don't use libraries like ActiveCable or socket.io, you have to build your own MessageID reconciliation so that you can have request/response cycles. Which is generally what you want (or eventually want) in a websocket-heavy application.
send(payload).then(reply => ...)Re: The hidden complexity of scaling WebSockets
#8Earlier quoted context omitted.
Node has similar libraries like Socket.IO too, but it over-abstracts it a bit in my opinion.
I've done my share of building websocket servers from scratch, but when you don't use libraries like ActiveCable or socket.io, you have to build your own MessageID reconciliation so that you can have request/response cycles. Which is generally what you want (or eventually want) in a websocket-heavy application. send(payload).then(reply => ...)
Yep, for our application, we have an `executionId` that is sent in essentially every single WebSocket message.
But client and server use it to maintain a record of events.
Re: The hidden complexity of scaling WebSockets
#9[deleted]
Re: The hidden complexity of scaling WebSockets
#10I recall another complication with websockets: IIRC it's with proxy load balancers, like binding a connection to a single connection server, even if the backend connection is using HTTP/2. I probably have the details wrong. I'm sure someone will correct my statement.
I think it's more that WebSockets are held open for a long time, so if you're not careful, you can get "hot" backends with a lot of connections that you can't shift to a different instance.
It can also be harder to rotate backends since you know you are disrupting a large number of active clients.