[paxys]

Before going all-in on websockets I'd like to caution people to thoroughly consider the server-side scaling challenges that come with it.

HTTP servers have already solved traffic management, load balancing, scaling up and down, zero downtime deployments, A/B tests and experimentation and lots more to such a degree that we don't have to even think about them anymore. All of these problems come to the forefront again when you have to scale websocket connections beyond a single server.

[rglover]

There's a (relatively) easy trick for this: Redis pubsub.

When a message comes into an instance, you push it to Redis and have all of your other instances subscribed to it. Messages sync in real-time and the experience is transparent.

I teach the technique here: https://cheatcode.co/courses/how-to-implement-real-time-data...

[Supermancho]

To be a bit clearer, you don't want to push websocket messages per se; eg auth negotiation or info requests. You do want to pubsub out conditioned messages that are generated by any given instance for the purpose of broadcast; eg "userX connected" or "userX said Y".

[mathgladiator]

I'm going all-in on WebSockets, but I've also seen how to solve all those problems at massive scale. You're right that these challenges are hard, and I don't believe we have an ideal shared offering yet.

We have a cultural challenge of how to manifest the opportunity and benefits presented by context rich communication over the entrenched ideology of statelessness and HTTP.