5 ms·
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number o
by twic 3y ago
The big problem i've run into with SSE is the connection limit [1]:
> Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com. (from Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).
The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all!
It's also quite natural, i think, to want to use multiple separate streams. It's very convenient to write separate endpoints for various kinds of data that a page might want, for example one for streaming numerical data, one for control messages, and one for descriptive events; or one for each panel on a dashboard. Here, you can hit the limit on a single page.
I wrote a thin layer over my HTTP server's APIs which lets me write a single handler which can send events via either SSE or a websocket. Then, when i build a page, i use websockets, but if i want to debug, i can still use curl to make a normal HTTP request. Also, other apps can use SSE to pull data, which only requires an HTTP client, not a websocket client.
[1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource
- chii 3y ago> It's also quite natural, i think, to want to use multiple separate streams. i dont think i'd call it natural per se - i'd say it's just "easy" to do so, and especially if each of these separate streams are managed by different teams, and it makes business sense to separate the responsibility. There should be a framework, perhaps, to allow "multiplexing" of multiple streams of events into one actual tcp connection. Of course, this requires some work, but i dont think it's actually that much extra work. It just needed to be planned out as a need, as it might be a tad hard to tack it on after the fact (tho that's not impossible either).
- deleted 3y ago[deleted]
- DaiPlusPlus 3y ago> The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all! You can use EventSource in a singleton worker and use postMessage to forward messages to all open browser tabs for the same origin.
- ranguna 3y agoThe original comment stands: it's harder.
- tehbeard 3y agoSharedWorker (the thing needed for a "singleton worker") only just made it into Safari the end of last year... plus you now have to handle multiplexing and demultiplexing for different tabs on both server and client. By the time that arrived and HTTP/2 had wide enough adoption, everyone's already used to building atop Websocket... Also the EventSource in the browser is heavily gimped. GET only, No custom headers, and last I checked you can forget about configuring any CORS stuff for credential passing.
- cassepipe 3y agoNot sure if that's what you are asking but there's a `withCredentials` option (which IIRC is the only possible option) I was looking at : https://stackoverflow.com/questions/61041389/managing-server-side-events-with-a-service-worker https://stackoverflow.com/questions/61041389/managing-server... Shared worker would actually allow for SSE in a service worker ! That's nice.
- anshumankmr 3y agoEventSource is bad. We were using it to connect to GPT 4 via our server acting as a middleware (we hosted the code for returning the LLM response on our server since our company's OpenAI API key is supposed to be private). However, previous developers had written a basic middleware to check if a req.body exists and if it contains a userId (since our server was handling multipler other things apart from this one component of the business logic). However, any such manipulation of the request body isn't possible with EventSource (and I felt that using a workaround such as passing the userId in the querystring could cause some security issue), so I ended up using the fetch() method to connect to our server for interacting with GPT 4.
- bullen 3y agoJust create more subdomains if you really need more sockets. Or move away from the browser. Browsers are toxic now.
- deleted 3y ago[deleted]
- nine_k 3y agoIn short, it reads to me as "HTTP/2 or don't bother". Not an unreasonable requirement for a serious modern web app.
- cassepipe 3y agoYes, but weirdly enough the most popular javascript for handling http, express, does not support HTTP2 ! Fastify does