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

121–130 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#121

Post by jpc0 »

deaf_coder wrote: post #120

The part where it says: > SSE works seamlessly with existing HTTP infrastructure: I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, e…

I had a similar issue at one point but if I remember correctly I just had to have my webserver send the header section without closing the connection.

Usually things would just get streamed through but for some reason until the full header was sent the proxy didn't forward and didn't acknowledge the connection.

Not saying that is your issue but definitely was mine.

Re: Server-Sent Events (SSE) Are Underrated

#122

Post by jpc0 »

anshumankmr wrote: post #98

SSE is not underrated. In fact it's being used by Open AI for streaming completions. It's just not always needed unlike the very obvious use cases for normal REST APIs and Websockets. It was a pain to figure out how to get it to work in a ReactJS codebase I was working on then and from what I remember Axios didn't support it then so I had to use native fetch to get it to work.

How long ago was this?

I seem to remember not having too many issue with useEffect and context on this.

Maybe the issue is you wanted to implement it in a singular react component when in reality you should be treating it like an other state library since it is something long lived that should live outside of react and pass data into react.

Re: Server-Sent Events (SSE) Are Underrated

#123

Post by Tiberium »

slow_typist wrote: post #91
Tiberium wrote: post #27

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

What makes you think the article is AI-written?

I've just spent too much time with different LLMs, and for example Claude really loves such bullet point lists. The article is full of them.

The whole structure with numbered sections really gives it away, humans don't write blog posts like that.

Re: Server-Sent Events (SSE) Are Underrated

#124

Post by sudhirj »

jpc0 wrote: post #121
deaf_coder wrote: post #120

The part where it says: > SSE works seamlessly with existing HTTP infrastructure: I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, e…

I had a similar issue at one point but if I remember correctly I just had to have my webserver send the header section without closing the connection. Usually things would just get streamed through but for some reason until the full header was sent the proxy didn't forward and didn't acknowledge the connection. Not saying that is your issue but definitely was mine.

Not entirely. If a load balancer is set to buffer say 4kb of data all the time, your SSE is stuck until you close the connection.

I think there is a HTTP/2 flush instruction, but no load balancer is obligated to handle it and your SSE library might not be flushing anyway.

Re: Server-Sent Events (SSE) Are Underrated

#125

Post by Igor_Wiwi »

deaf_coder wrote: post #120

The part where it says: > SSE works seamlessly with existing HTTP infrastructure: I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, e…

thanks, updated the article with your comment

Re: Server-Sent Events (SSE) Are Underrated

#126

Post by deaf_coder »

sudhirj wrote: post #124
jpc0 wrote: post #121

Earlier quoted context omitted.

I had a similar issue at one point but if I remember correctly I just had to have my webserver send the header section without closing the connection. Usually things would just get streamed through but for some reason until the full header was sent the proxy didn't forward and didn't acknowledge the connection. Not saying that is your issue but definitely was mine.

Not entirely. If a load balancer is set to buffer say 4kb of data all the time, your SSE is stuck until you close the connection. I think there is a HTTP/2 flush instruction, but no load balancer is obligated to handle it and your SSE library might not be flushing anyway.

In my case with this load balancer, I think it's just badly written. I think it is set to hold ALL data until the server ends the connection. I have tried leaving my SSE open to send over a few megabytes worth of data and the load balancer never forwarded it at all until I commanded the server to close the connection.

The dev who wrote that code probably didn't think too much about memory efficiency of proxying HTTP connections or case of streaming HTTP connections like SSE.

Re: Server-Sent Events (SSE) Are Underrated

#127

Post by deaf_coder »

realPubkey wrote: post #7
condiment wrote: post #4

So it’s websockets, only instead of the Web server needing to handle the protocol upgrade, you just piggyback on HTTP with an in-band protocol. I’m not sure this makes sense in 2024. Pretty much every web server supports websockets at this point, and so do all of the browsers. You can easily impose the constraint on your code that communication through a websocket is mono-directional. And the capability to broadcast…

Yes most servers support websockets. But unfortunately most proxies and firewalls do not, especially in big company networks. Suggesting my users to use SSEs for my database replication stream solved most of their problems. Also setting up a SSE endpoint is like 5 lines of code. WebSockets instead require much more and you also have to do things like pings etc to ensure that it automatically reconnects. SEEs with the…

going slightly off the tangent here, does FaaS cloud providers like AWS, CloudFlare, and etc support SSEs?

Last time I checked, they don't really support it.

Re: Server-Sent Events (SSE) Are Underrated

#128

Post by b4ckup »

fitsumbelay wrote: post #92
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…

I hate to suggest a solution before testing it myself so apologies in advance but I have a hunch that Broadcast Channel API can help you detect browser tab opens on client side. New tabs won't connect to event source and instead listen for localStorage updates that the first loaded tab makes. https://www.google.com/search?q=can+I+use+BroadcastChannel+A... The problem in this case is how to handle the first tab closin…

This sounds like a good use case for using a service worker. All tabs talk to the service worker and the worker is the single instance that talks to the backend and can use only one connection. Maybe there are some trade offs for using SSE in web workers, I'm not sure.

Re: Server-Sent Events (SSE) Are Underrated

#129

Post by seabrookmx »

ksajadi wrote: post #84
nhumrich wrote: post #81

Earlier quoted context omitted.

You don't need http2 on the actual backend. All limitations for SSE/http1 are browser level. Just downgrade to http1 from the LB to backend, even without SSL. As long as LB to browser is http2 you should be fine.

Isn't that going to affect the whole multiplexing / multiple connection of SSEs?

I don't think so?

HTTP 1.1 still supports Keep-Alive.

Re: Server-Sent Events (SSE) Are Underrated

#130

Post by motorest »

deaf_coder wrote: post #120

The part where it says: > SSE works seamlessly with existing HTTP infrastructure: I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, e…

> SSE works seamlessly with existing HTTP infrastructure:

To stress how important it is to correct this error, even Mozilla's introductory page on server-sent events displays prominently with a big red text box that server-sent events are broken when not used over HTTP/2 due to browser's hard limit on open connections.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

Edit: I just saw the issue pointed out further down in the discussion

https://news.ycombinator.com/item?id=42511562

Post reply on HN