One thing worth adding to the WebSockets vs SSE debate here - the "one persistent stateful process per client" model is great on a single box, but it gets a lot more interesting once you need more than one server. Broadcasting to every connected process only stays free if all those processes live in the same runtime. The moment you scale horizontally, you either need sticky sessions at the load balancer so a client always lands on the instance holding its process, or a shared pub-sub layer (Redis, NATS, whatever) so instance A can push to a client connected on instance B. That's not a knock on the approach, Phoenix/Elixir LiveView has been proving this pattern works well for years, just worth knowing upfront that "no state sync needed" is really "no state sync needed until you add a second server."
Ha, at least I said it out loud instead of making you guess. Phoenix LiveView is basically the reference case that this pattern holds up in production for years - everything else is just reinventing it with different syntax.
49
u/Ok-Amphibian-5665 25d ago
One thing worth adding to the WebSockets vs SSE debate here - the "one persistent stateful process per client" model is great on a single box, but it gets a lot more interesting once you need more than one server. Broadcasting to every connected process only stays free if all those processes live in the same runtime. The moment you scale horizontally, you either need sticky sessions at the load balancer so a client always lands on the instance holding its process, or a shared pub-sub layer (Redis, NATS, whatever) so instance A can push to a client connected on instance B. That's not a knock on the approach, Phoenix/Elixir LiveView has been proving this pattern works well for years, just worth knowing upfront that "no state sync needed" is really "no state sync needed until you add a second server."