Comment by fefe23
2 days ago
This is an astonishingly bad idea. Don't do this.
Use HTTP server-sent events instead. Those can keep the connection open so you don't have to poll to get real-time updates and they will also let you resume from the last entry you saw previously.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
Yeah, but in real life, SSE error events are not robust, so you still have to do manual heartbeat messages and tear down and reestablish the connection when the user changes networks, etc. In the end, long-polling with batched events is not actually all that different from SSE with ping/pong heartbeats, and with long-polling, you get the benefit of normal load balancing and other standard HTTP things
Never had to use ping/pong with SSE. The reconnect is reliable. What you probably had happen was your proxy or server return a 4XX or 5XX and that cancels the retry. Don't do that and you'll be fine.
SSE works with normal load balancing the same as regular request/response. It's only stateful if you make your server stateful.
Correct. In the end, mechanically, nothing beats long polling. Everything ends up converging at which point you may as well just long poll.
But SSE is a standard HTTP thing. Why would you not be able to do "normal load balancing"?
I would also rather not have a handful of long-polling loops pollute the network tab.
“Normal load balancing” means “Request A goes to server A”, “Request B goes to server B” and there is no state held in the server, if there is a session its stored in a KV store or database which persists.
With SSE the server has to be stateful, for load balancing to work you need to be able to migrate connections between servers. Some proxies / load balancers don’t like long lasting connections and will tear them down if there has been no traffic so your need to constantly send a heart beat.
I have deployed SSE, I love the technology, I wouldn’t deploy it if I don’t control the end devices and everything in between, I would just do long polling.
4 replies →
Or use Braid-HTTP, which gives you both options.
(Details in the previous thread on HTTP Feeds: https://news.ycombinator.com/item?id=30908492 )
Isn't SSE limited to like 12 tabs or something? I remember vividly reading about a huge limitation on that hard limit.
6 tabs is the limit on SSE. In my opinion Server Sent Events as a concept is therefore not usable in real world scenarios as of this limitation or error-detection around that limitation. Just use Websockets instead.
This is a misinformed take. H2/H3 gives you 100+ connections. Even then you only need h2 from the proxy to the browser.
If you have to use H1 for some reason you can easily prune connections with the browser visibility api.
that's an http 1.1 only limitation. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
2 replies →