News for hackers. Stuff that matters.

A comment on Back to basics: Why we chose long-polling over websockets. Parent comment

Re:Back to basics: Why we chose long-polling over websockets by lunarcave on Sunday January 05, 2025 @04:22AM (#42600661)
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.

[ Parent | on HN ]
Re:Back to basics: Why we chose long-polling over websockets by gorjusborg on Sunday January 05, 2025 @07:31AM (#42601356)
> 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.

[ Parent | on HN ]
Re:Back to basics: Why we chose long-polling over websockets by josephg on Sunday January 05, 2025 @08:28AM (#42601607)
What the GP commenter might have meant is that websockets support binary message bodies. SSE does not.
[ Parent | on HN ]