Comment by akira2501 | Hacker News Reader

Comment by akira2501 | Hacker News Reader

Parent Full thread

> Is this a full or partial state update?

It's a message. Mapping protocol units to messages was always your business.

> What if the client misses an update?

Sequence numbers on updates combined with a "fill in" mechanism through a separate request.

> What if the client loses connectivity?

Then more important things won't work either.

> How can the server detect and clean up clients that have disappeared?

The SSE client will restart dropped connections. You can have the server opportunistically close connections that haven't received messages recently. The browser will automatically reconnect if the object is still alive on the client side.

> For that, I would say that long polling (or even just polling) is the clear winner.

Coordinating polling intervals while simultaneously avoiding strong bursting behavior is genuinely not fun.

All that speaks to the point that the underlying protocol does not matter that much. The larger design is a more important consideration than the specific push tech.

None of this favors SSE, or anything else for that matter. You still have to think about bursting / thundering herd behavior after server restarts, which would affect any protocol. The browser auto reconnecting doesn't mean you can assume the connection remains alive indefinitely if a reconnect hasn't happened; you may want periodic notifications as a keepalive to enable more immediate recovery. Long-lived server state introduces its own distributed coordination and cleanup problems, which strict request-reply polling sidesteps entirely. Etc.

There is no silver bullet, only tradeoffs in the design space that need to be matched to your application's requirements.

> the underlying protocol does not matter that much

Then why is long polling the "clear winner?"

For interoperability with HTTP tooling (eg, curl) it is the clear winner

SSE, which is just an HTTP request, works perfectly fine with curl or any other library which makes HTTP requests.

Curl and most libraries don't unwrap SSE for you out of the box, you lose the one-shot request-response leading to nonstandard flow control in integrations, etc.

Sure you can find random libraries to help but they do need to be specifically built for SSE. Plain (long-)polling does not need any of that, which makes it more attractive from an API interoperability standpoint.

Reply on news.ycombinator.com