Hacker News Reader

Comment by jallmann | Hacker News Reader

Browser push APIs are hard to design well regardless of the underlying protocol (SSE, Long Polling, Websockets, etc). There are a bunch of things to consider:

- Is this a full or partial state update?

- What if the client misses an update?

- What if the client loses connectivity?

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

How those are answered in turn raise more questions.

SSE or long polling or even WebSockets is a relatively unimportant implementation detail. IMO the bigger consideration should probably be ease-of-use and tooling interoperability. For that, I would say that long polling (or even just polling) is the clear winner.

View on HN

> 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.

This is one of my favorite articles along these lines:

https://blog.sequin.io/events-not-webhooks/

Yeah that is a great article, and I agree that long polling an events endpoint along with a cursor gets you most of the way there for browser clients. At that point, things start to resemble the Kafka protocol.

Great article, thanks for sharing. NATS is an excellent option along these lines, particularly with their nats.ws library

https://nats.io/

Reply on news.ycombinator.com