Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events (SSE) Are Underrated

igorstechnoclub.com

Post reply on HN
Print view View original

51–60 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#51

Post by robocat »

atombender wrote: post #40
dugmartin wrote: post #8

It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).”

One of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that si…

Presumably you try SSE, and on failure fallback to something else like WebSockets?

Push seems to require supporting multiple communication protocols to avoid failure modes specific to one protocol - and libraries are complex because of that.

Re: Server-Sent Events (SSE) Are Underrated

#52

Post by raggi »

RadiozRadioz wrote: post #12
dugmartin wrote: post #8

It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).”

That is a very low number. I can think of many reasons why one would end up with more. Does anyone know why it is so low?

The number was set while Apache was dominant and common deployments would get completely tanked by a decent number of clients opening more conns than this. c10k was a thing once, these days c10m is relatively trivial

Re: Server-Sent Events (SSE) Are Underrated

#53

Post by uncomplexity_ »

remram wrote: post #47
uncomplexity_ wrote: post #41

Earlier quoted context omitted.

wait let's check this https://news.ycombinator.com/item?id=42511562 at https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... it says "Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" i…

Or a SharedWorker that creates a single SSE connection for all your tabs. SharedWorker is not very complicated but it's another component to add. It would be cool if this was built into SSE instead.

okay wtf this is amazing, seems usable with websockets too.

usage of Shared Web Workers https://dev.to/ayushgp/scaling-websocket-connections-using-s...

caniuse Shared Web Workers 45% https://caniuse.com/sharedworkers

caniuse BroadcastChannel 96% https://caniuse.com/broadcastchannel

Re: Server-Sent Events (SSE) Are Underrated

#54

Post by hamandcheese »

mikojan wrote: post #43
hamandcheese wrote: post #39

I tried implementing SSE in a web project of mine recently, and was very surprised when my website totally stopped working when I had more than 6 tabs open. It turns out, Firefox counts SSE connections against the 6 host max connections limit, and gives absolutely no useful feedback that it's blocking the subsequent requests due to this limit (I don't remember the precise error code and message anymore, but it left m…

That's only if not used over HTTP/2 and it says so in the docs too[0] [0]: https://developer.mozilla.org/en-US/docs/Web/API/EventSource

AFAIK browsers require https with http2. This is a locally running server/app which will probably never have https. Maybe there is an exception for localhost, I'm not sure.

Re: Server-Sent Events (SSE) Are Underrated

#55

Post by hamandcheese »

remram wrote: post #47
uncomplexity_ wrote: post #41

Earlier quoted context omitted.

wait let's check this https://news.ycombinator.com/item?id=42511562 at https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... it says "Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" i…

Or a SharedWorker that creates a single SSE connection for all your tabs. SharedWorker is not very complicated but it's another component to add. It would be cool if this was built into SSE instead.

Ultimately this is what I did. But if you need or want per-tab connection state it will get complicated in a hurry.

Re: Server-Sent Events (SSE) Are Underrated

#56

Post by nchmy »

atombender wrote: post #40
dugmartin wrote: post #8

It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).”

One of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that si…

FYI, the dev of that library created a new, better Event Source client

https://github.com/rexxars/eventsource-client

Re: Server-Sent Events (SSE) Are Underrated

#57

Post by nchmy »

apitman wrote: post #10

> Perceived Limitations: The unidirectional nature might seem restrictive, though it's often sufficient for many use cases For my use cases the main limitations of SSE are: 1. Text-only, so if you want to do binary you need to do something like base64 2. Browser connection limits for HTTP/1.1, ie you can only have ~6 connections per domain[0] Connection limits aren't a problem as long as you use HTTP/2+. Even so, I d…

You can do fetch and readable stream with SSE - here's an excellent client library for that

https://github.com/rexxars/eventsource-client

Re: Server-Sent Events (SSE) Are Underrated

#58

Post by mardifoufs »

robocat wrote: post #51
atombender wrote: post #40

Earlier quoted context omitted.

One of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that si…

Presumably you try SSE, and on failure fallback to something else like WebSockets? Push seems to require supporting multiple communication protocols to avoid failure modes specific to one protocol - and libraries are complex because of that.

But then why not just use websockets?

Re: Server-Sent Events (SSE) Are Underrated

#59

Post by atombender »

nchmy wrote: post #56
atombender wrote: post #40

Earlier quoted context omitted.

One of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that si…

FYI, the dev of that library created a new, better Event Source client https://github.com/rexxars/eventsource-client

Yes, I know. We both work at Sanity, actually! The reason I didn't mention it was that the newer library isn't a straight polyfill; it offers a completely different interface with async support and so on.

Re: Server-Sent Events (SSE) Are Underrated

#60

Post by nchmy »

uncomplexity_ wrote: post #53
remram wrote: post #47

Earlier quoted context omitted.

Or a SharedWorker that creates a single SSE connection for all your tabs. SharedWorker is not very complicated but it's another component to add. It would be cool if this was built into SSE instead.

okay wtf this is amazing, seems usable with websockets too. usage of Shared Web Workers https://dev.to/ayushgp/scaling-websocket-connections-using-s... caniuse Shared Web Workers 45% https://caniuse.com/sharedworkers caniuse BroadcastChannel 96% https://caniuse.com/broadcastchannel

Yeah, the issue with SharedWorkers is that Android Chromium doesn't support it yet. https://issues.chromium.org/issues/40290702

But rather than Broadcast Channel, you can also use the Web Locks API (https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...) rather than Broadcast Channel

This library (https://github.com/pubkey/broadcast-channel/blob/master/src/...) from the fantastic RxDB javascript DB library uses WebLocks with a fallback to Broadcast Channel. But, WebLocks are supported on 96% of browsers, so probably safe to just use it exclusively now.

Post reply on HN