SSE is phenomenal and underutilized because it wasn't supported by IE.
Server-sent events
41–50 of 111 posts
Re: Server-sent events
#42Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...
This problem is fixed by using HTTP/2.
No, the browser's HTTP connection limits still apply on HTTP2, each `EventSource` per tab counts against this limit of I think 6 (?) connections.
Websockets to my knowledge have no such limit because they are not HTTP requests.
Re: Server-sent events
#43Earlier quoted context omitted.
I've never worked with Web Workers, but the doc page mentions them at the very top. Isn't that the intended workaround? Have a background thread that receives the events & coordinates, rather than having each page deal with them?
Yes, that's `ShardedWorker`.
I wanted so use these in a project recently, only to find out that they aren't supported on Chrome for Android. This makes them non-usable for me, since there is no drop-in polyfill available yet.
Re: Server-sent events
#44What is the advantage of SSE over streaming ndjson?
Built-in client API for parsing and event dispatching. Data doesn't have to be JSON encoded.
But fundamentally nothing that Comet, steaming XHR, etc, WebSockets, can't do.
Re: Server-sent events
#45Note 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 implementat…
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.
Re: Server-sent events
#46I wish there were a way to push not just anonymous data/events but http resources, to similar effect.
SSE & websockets & http streams can send anonymous data, but I'd like to be able to send an actual thing. As per the most core architecture of the web:
> Axiom 0a: Universality 2. Any resource of significance should be given a URI. https://www.w3.org/DesignIssues/Axioms.html#uri
Or alternatively,
> Cool URLs don't change (implicitly, cool things have URLs, see above). https://www.w3.org/Provider/Style/URI
Instead of pushing to a chat app an anonymous blob of json for a chat message to a room, the server could assert a /room/42/msg/c0f3 resource, could identify universally what it is it's sending. The advantage would be so high. It'd become a standard way to assert a resource, to make known a fact, that would be viable across systems. Further http requests to the resource would just work. Folks could link to the resource. How cool it would be if we could send not just data but resources?
We have come glancingly close to getting such a thing so many times. The HyBi mailing list that begat websockets had a number of alternate more resourceful ideas floating around such as a BEEP protocol that allowed patterns beyond request/response of resources. The browser actually implements an internal protocol that uses HTTP2/push to send resourceful messages, web push protocol/RFC8030, https://datatracker.ietf.org/doc/html/rfc8030.
But the underlying http2/push was de-implemented for webserving in general, and even when it was available, it lacked the oft requested ability to get notice of new pushed resources. (https://github.com/whatwg/fetch/issues/65 was an old request. https://github.com/whatwg/fetch/issues/607 had some steam in making it happen.) Tragic backwards moves in my view, and never acknowledged by blink-dev when protests arose.
The best we have today is to stream json-ls events, which have an @id property identifying them. But developers would have to snoop these events, and store them in a service worker, to make them actually accessible as http resources.
I continue to hold hope eventually we'll get better at using urls to send data, to assert new things happening... But it's been nearly 30 years of me hoping, and with some fleeting exceptions the browser teams have seemed disinterested in making urls cool, in spite of a number of requests. We've been left at un-web side-channels like SSE & Websockets for a long long time now. Wouldn't it be nice to see some real growth for http capabilities that we really can use, that are more than abstract underlying transport tweaks like h2 and h3?
Re: Server-sent events
#47Earlier quoted context omitted.
Yes, that's `ShardedWorker`.
I wanted so use these in a project recently, only to find out that they aren't supported on Chrome for Android. This makes them non-usable for me, since there is no drop-in polyfill available yet.
If you are doing websocket in there, you could fall back to main thread, but it comes at the cost of code duplication.
Re: Server-sent events
#48Curious why is this trending? Btw sse are pretty great, only thing I don't get is why they don't allow for binary payloads. That'd have been the icing on the cake.
This got into the zeitgeist somehow. I just implemented my first SSE app with FastAPI last week, then I saw a youtube video and this post!
I was implementing something with websockets and asked chatgpt to tell me about modern alternatives. In my years of full-stack… I hadn’t heard of SSE, or at least never got why I should care.
Damn, I see the limitations of REST, but I was building state machines and custom protocols with websockets. It’s nice to prototype in REST again.
REST+SSE ftw, I guess!
Re: Server-sent events
#49How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?
[deleted]
Re: Server-sent events
#50I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
One major issue I encountered with SSE is dealing with reconnection. WebSocket makes it very easy to detect differences between a loss of network connectivity, a server dying, and a client exiting properly (eg: closing the tab), on either side of the socket. Maybe there are facilities to do so with SSE that I don't know of, but my experience in reliable server-to-client-only comms with it has been a bit rough.
You pretty much just have to listen for and handle premature closing of the underlying TCP connection. It's the only form of dead peer detection you'll get if someone just abrubtly closes their browser tab.