[pieter]

Note that this really isn’t anything except the agreement to send messages separated by 2 new lines. The SSE object in browsers is old and quirky; for example, it only supports GET requests, which means you’ll hit path length limits if you use it for something like LLM completion with large prompts.

Luckily since there’s nothing special about the browser support, you can very easily replace it with custom implementations. https://www.npmjs.com/package/@microsoft/fetch-event-source for example offers mostly the same API, but does offer POST requests and a bunch of other goodies.

[jraph]

There is this agreement, and also the fact that browsers can forget previous messages, unlike any xhr-based custom implementation since the EventSource object does not provide methods to access previous contents. I don't know how well this package handles this.

I agree with the note about the auto retry mechanism of EventSource. It does no good, is unavoidable and a big annoyance. The work we had to do to work around it in Tracim (previous job) [1] was pure madness. I see this part has not been touched since I left by the way.

https://github.com/tracim/tracim/blob/develop/frontend_lib/s...

[hamandcheese]

This seems like a great solution for streaming responses scoped to a single request. Neat!

I've always used SSEs to open a more persistent comms channel to a browser which creates way more state and complexity both on the client and the server.