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

131–140 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#131

Post by cle »

> Automatic Reconnection

I wouldn't characterize this as "automatic", you have to do a lot of manual work to support reconnection in most cases. You need to have a meaningful "event id" that can be resumed on a new connection/host somewhere else with the Last-Event-Id header. The plumbing for this event id is the trivial part IMO. The hard part is the server-side data synchronization, which is left as an exercise for the reader.

Also, God help you if your SSE APIs have side effects. If the API call is involved in a sequence of side-effecting steps then you'll enter a world of pain by using SSE. Use regular HTTP calls or WebSockets. (Mostly b/c there's no cancellation ack, so retries are often racy.)

Re: Server-Sent Events (SSE) Are Underrated

#132

Post by anshumankmr »

jpc0 wrote: post #122
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.

Pretty much a year and a half back (I think it was March 2023). We had a real complicated set up back then, since I couldn't put our Open AI client key on the client side so I wrote an end point to to call Open AI's GPT3.5 API and then send that back to the front end to get the "typewriter" effect that they had on the frontend. It was quite broken back then cause sometimes random artifacts used to pop up in response, and some chunks came along with one another requiring me to write some really convoluted deserializing logic for it.

Re: Server-Sent Events (SSE) Are Underrated

#133

Post by Keithamus »

b4ckup wrote: post #128
fitsumbelay wrote: post #92

Earlier quoted context omitted.

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.

BroadcastChannel is a better solution for a couple of reasons. Service Workers are better at intercepting network requests and returning items from a cache, there’s some amount of additional effort to do work outside of that. The other thing is they’re a little more difficult to set up. A broadcast channel can be handled in a couple lines of code, easily debuggable as they run on the main thread, and they’re more suited to the purpose.

Re: Server-Sent Events (SSE) Are Underrated

#134

Post by leni536 »

apitman wrote: post #117
leni536 wrote: post #101

Earlier quoted context omitted.

Supposedly websockets (the protocol) support authorization headers, but often there are no APIs for that in websocket libraries, so people just abuse the subprotocols header in the handshake.

I don't think the problem is libraries. Browsers don't support this.

Sure, I didn't mean to distinguish browsers and the JS websocket API and websocket libraries in other languages.

Re: Server-Sent Events (SSE) Are Underrated

#135

Post by fitsumbelay »

Keithamus wrote: post #133
b4ckup wrote: post #128

Earlier quoted context omitted.

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.

BroadcastChannel is a better solution for a couple of reasons. Service Workers are better at intercepting network requests and returning items from a cache, there’s some amount of additional effort to do work outside of that. The other thing is they’re a little more difficult to set up. A broadcast channel can be handled in a couple lines of code, easily debuggable as they run on the main thread, and they’re more sui…

agreed. Workers was one of my first thoughts but I think BroadcastChannel delivers with much lower LOE

Re: Server-Sent Events (SSE) Are Underrated

#136

Post by nhumrich »

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?

No. That's all handled in the browser and load balancer.

Re: Server-Sent Events (SSE) Are Underrated

#137

Post by abnercoimbre »

Tiberium wrote: post #123
slow_typist wrote: post #91

Earlier quoted context omitted.

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.

I remember reading the post and feeling it was inorganic.

After your comment I re-read everything and you're correct: this is a very common template for Claude type answers.

LLM-generated comments on HN are against the guidelines. Would the same apply to blog post submissions?

Re: Server-Sent Events (SSE) Are Underrated

#138

Post by upghost »

nhumrich wrote: post #83
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?

The socket closes. Most languages bubble this back up to you with a connection closed exception. In python async world, it would be a cancelled error.

I haven't seen a library that does that yet, including Python. Usually you just throw messages into the void. Do you know of a specific library that does that?

Re: Server-Sent Events (SSE) Are Underrated

#139

Post by nhumrich »

upghost wrote: post #138
nhumrich wrote: post #83

Earlier quoted context omitted.

The socket closes. Most languages bubble this back up to you with a connection closed exception. In python async world, it would be a cancelled error.

I haven't seen a library that does that yet, including Python. Usually you just throw messages into the void. Do you know of a specific library that does that?

I use starlette + SSE

Re: Server-Sent Events (SSE) Are Underrated

#140

Post by upghost »

nhumrich wrote: post #139
upghost wrote: post #138

Earlier quoted context omitted.

I haven't seen a library that does that yet, including Python. Usually you just throw messages into the void. Do you know of a specific library that does that?

I use starlette + SSE

Thanks, I will check that out. If they properly handle client disconnects I'll pull this in.
Post reply on HN