The SSE protocol is actually just a long-running stream like I mentioned but with specific formatting for each chunk (id, event, and data fields)

as a side note, eventkit actually exports utilities to support SSE both on client and server. The reason you'd want to use eventkit in either case is because it ships with some extra transformation and observability goodies. https://hntrl.github.io/eventkit/guide/examples/http-streami...

A lot of times, what people need is a bidirectional connection yet somehow they convince themselves that SSE (or sometimes even long polling is better for the job)... But they end up with two different types of streams; HTTP for writes and responses and SSE for passively consuming real-time data... Two different stream types with different lifecycles; one connection could fail while the other is fine... There is no way to correctly identify what is the current connection status of the app because there are multiple statuses and data comes from multiple streams.

https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...

Unless you mean on HTTP2? But aren't WS connections also multiplexed over HTTP2 in that case?

It should say "When used over HTTP/1" instead of "When not used over HTTP/2" because nowadays we also have HTTP/3, and browsers barely even use HTTP/1, so I would say it's pretty safe to ignore that warning.

> Unless you mean on HTTP2?

Any version of HTTP that supports multiplexing.

> But aren't WS connections also multiplexed over HTTP2 in that case?

There is RFC 8441 but I don't think it's actually implemented in the browsers.

Found this: https://github.com/mattermost/mattermost/issues/30285

It looks like it's supported in Chrome and Firefox but not in Safari.

These are tools, not religions.

Websockets have some real downsides if you don't need bidirectional comms.

(it's not SSE in particular, but it demonstrates that you can have a long running stream like SSE)

No server traffic for 100+ sec officially results in a 524, so you could possibly make that keepalive interval longer, but I haven't tested it.

Make sure to have the new style cache rule with Bypass cache selected and absolutely make sure you are using HTTP/2 all the way to the origin.

The 6 connections per browser limit of HTTP/1.1 SSE was painful, and I am pretty sure auto negotiation breaks, often in unexpected ways with a HTTP/1.1 origin.

That said, I like SSE for unidirectional string-encoded events.

Also I don't see it being much easier here than a few primitives and learning about generator functions if you haven't had experience with them. I appreciate the helper, but the API is pretty reasonable as-is IMO

The only problem is, if you want to customize the request (e.g. send a POST or add a header),you have to use a third-party implementation (e.g. one from Microsoft [1]), but I hope this can be fixed in the standards later.

[1]: https://www.npmjs.com/package/@microsoft/fetch-event-source

I do like the reactive approach (in fact, I’ve reinvented something similar over SSE). I feel a standards-based solution is just ever so slightly more robust/universal.