Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

Would there be any technical benefit to this over using server sent events (SSE)?

Both are similar in that they hold the HTTP connection open and have the benefit of being simply HTTP (the big plus here). SSE (at least to me) feels like it's more suitable for some use cases where updates/results could be streamed in.

A fitting use case might be where you're monitoring all job IDs on behalf of a given client. Then you could move the job monitoring loop to the server side and continuously yield results to the client.

View on HN

I got interested and found this nice thread on SO: https://stackoverflow.com/a/5326159

One of the drawbacks, as I learned - SSE have limit on number of up to ~6 open connections (browser + domain name). This can quickly become a limiting factor when you open the same web page in multiple tabs.

I've gotten around this by using the Page Visibility API - https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi.... Close the SSE connection when the page is hidden, and re-open when it becomes visible again.

As the other two comments mentioned, this is a restriction with HTTP/1.1 and it would apply also to long polling connections as well.

Syncing state across multiple tabs and windows is always a bit tricky. For SSE, I'd probably reach for the BroadcastChannel API. Open the SSE connection in the first tab and have it broadcast events to any other open tab or window.

…if you’re using http/1.1. It’s not an issue with 2+

Not an issue if you’re using HTTP/2 due to how multiplexing happens.

Good point! We did consider SSE, but ultimately decided against it due to the way we have to re-implement response payloads (one for application/json and one for text/event-stream).

I've not personally witnessed this, but people on the internets have said that _some_ proxies/LBs have problems with SSE due to the way it does buffering.

> we have to re-implement response payloads (one for application/json and one for text/event-stream)

I am curious about what you mean here. The 'text/event-stream' allows for abitrary event formats, it just provides structure for EventSource to be able to parse.

You should only need one 'text/event-stream' and should be able send the same JSON via normal or SSE response.

What the GP commenter might have meant is that websockets support binary message bodies. SSE does not.

I tried using SSE and found it didn't work for my use case, it was broken on mobile. When users switched from the browser to an app and back, the SSE connection was broken and they wouldn't receive state updates. Was easier to do long polling

The standard way to fix that is to send ping messages every ~15 seconds or something over the SSE stream. If the client doesn’t get a ping in any 20 second window, assume the sse stream is broken somehow and restart it. It’s complex but it works.

The big downside of sse in mobile safari - at least a few years ago - is you got a constant loading spinner on the page. Thats bad UX.

Not sure about the default `EventSource` object in JavaScript, but the Microsoft polyfill that I use (https://github.com/Azure/fetch-event-source) supports `POST` and there's an option `openWhenHidden` which controls how it reacts to users tabbing away.

SSE are being removed from various stacks and implementations

That's the dumbest thing I've ever heard. SSE is just a response type for normal HTTP. Explain exactly what you mean cause that's like saying that are removing response types from HTTP.

Yup; would also like a citation on that.

Reply on news.ycombinator.com