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

31–40 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#31

Post by sabareesh »

apitman wrote: post #22
piccirello wrote: post #16

I utilized SSE when building automatic restart functionality[0] into Doppler's CLI. Our api server would send down an event whenever an application's secrets changed. The CLI would then fetch the latest secrets to inject into the application process. (I opted not to directly send the changed secrets via SSE as that would necessitate rechecking the access token that was used to establish the connection, lest we send c…

Generally you're going to want to send ping events pretty regularly (I'd default to every 15-30 seconds depending on application) whether you're using SSE, WebSockets, or something else. Otherwise if the server crashes the client might not know the connection is no longer live.

Yeah with cloudflare you need to do it every 30 seconds as the timeout is is 60 seconds

Re: Server-Sent Events (SSE) Are Underrated

#32

Post by jiggawatts »

SahAssar wrote: post #30
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).”

There is little reason to not use HTTP/2 these days unless you are not doing TLS. I can understand not doing HTTP/3 and QUIC, but HTTP/2?

Corporate proxy servers often downgrade connections to HTTP 1.1 because inertia and lazy vendors.

Re: Server-Sent Events (SSE) Are Underrated

#33

Post by upghost »

Does anyone have a good trick for figuring out when the client side connection is closed? I just kill the connection on the server every N minutes and force the client to reconnect, but it's not exactly graceful.

Secondly, on iOS mobile, I've noticed that the EventSource seems to fall asleep at some point and not wake up when you switch back to the PWA. Does anyone know what's up with that?

Re: Server-Sent Events (SSE) Are Underrated

#34

Post by emmanueloga_ »

Tiberium wrote: post #27

Also, another day, another mostly AI-written article on HN's top page :)

It’s funny how HN has a mix of people who think AGI is just around the corner, people trying to build/sell stuff that uses LLMs, and others who can’t stand LLM-generated content. Makes me wonder how much overlap there is between these groups.

Re: Server-Sent Events (SSE) Are Underrated

#35

Post by henning »

They are handy for implementing simple ad-hoc hot reloading systems as well. E.g. you can have whatever file watcher you are using call an API when a file of interest changes that sends an event to listening clients on the frontend. You can also trigger an event after restarting the backend if you make an API change by triggering the event at boot time. Then you can just add a dev-only snippet to your base template that reloads the page or whatever. Better than nothing if your stack doesn't support it out of the box and doesn't take very much code or require adding any additional project dependencies. Not as sophisticated as React environments that will only reload a component that changed and only do a full page refresh if needed, but it still gives a nice, responsive feeling when paired with tools that recompile your backend when it changes.

Re: Server-Sent Events (SSE) Are Underrated

#36

Post by foota »

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?

Probably because without http/2 each would require a TCP connection, which could get expensive.

Re: Server-Sent Events (SSE) Are Underrated

#37

Post by jesprenj »

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).”

You can easily multiplex data over one connection/event stream. You can design your app so that it only uses one eventstream for all events it needs to receive.

Re: Server-Sent Events (SSE) Are Underrated

#38

Post by jesprenj »

upghost wrote: post #33

Does anyone have a good trick for figuring out when the client side connection is closed? I just kill the connection on the server every N minutes and force the client to reconnect, but it's not exactly graceful. Secondly, on iOS mobile, I've noticed that the EventSource seems to fall asleep at some point and not wake up when you switch back to the PWA. Does anyone know what's up with that?

Send a dummy event and see if you get an ACK in response. Depends on the library you're using.

Re: Server-Sent Events (SSE) Are Underrated

#39

Post by hamandcheese »

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 me very clueless for a while). It was only when I stared at the lack of corresponding server side logs that it clicked.

I don't know if this same problem happens with websockets or not.

Re: Server-Sent Events (SSE) Are Underrated

#40

Post by atombender »

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 simulate SSE over fetch/XHR, but it would be nice to not need to add the bloat.

[1] https://github.com/EventSource/eventsource

Post reply on HN