> Websockets require a central broker to pass messages through when you scale past one process I believe that this is one of the big advantages of SSE vs. WebS

> Websockets require a central broker to pass messages through when you scale past one process I believe that this is one of the big advantages of SSE vs. WebSockets. Unlike websockets, an SSE connection is just an HTTP request, just one that has a particular format and is conventionally long-lived. You don't need a broker and you can probably implement it yourself on top of whatever HTTP server library that you're already using. And it already contains functionality for dealing with network unreliability [1]. I've often thought that it would be really good to have better support for SSE in HTTP caching HTTP proxies. Then you could have nginx for example sitting infront of your SSE endpoints serving multiple clients with a single SSE stream to your backend. Just based on the caching headers and a little knowledge of `Last-Event-ID`. [1]: You can encode any state you require to resume the connection into Last-Event-ID.