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

141–150 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#141

Post by whateveracct »

kdunglas wrote: post #14

A while ago I created Mercure: an open pub-sub protocol built on top of SSE that is a replacement for WebSockets-based solutions such as Pusher. Mercure is now used by hundreds of apps in production. At the core of Mercure is the hub. It is a standalone component that maintains persistent SSE (HTTP) connections to the clients, and it exposes a very simple HTTP API that server apps and clients can use to publish. POST…

I've used Mercure before at a startup of mine. Self hosted. Worked great! And still works to this day (I haven't actively worked on that startup for years myself.)

Re: Server-Sent Events (SSE) Are Underrated

#142

Post by nchmy »

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…

Rather than Broadcast Channel, you can use the Web Locks API (https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...). This handles the leader election pretty seamlessly because all tabs try to become the leader and only one actually can.

This library (https://github.com/pubkey/broadcast-channel) 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

Re: Server-Sent Events (SSE) Are Underrated

#143

Post by nchmy »

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…

Weblocks (https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...) are an even better way to do this than Broadcast Channel

Re: Server-Sent Events (SSE) Are Underrated

#144

Post by b4ckup »

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…

I disagree. You can just postMessage to communicate with the service worker and therefore I imagine the code using broadcast channel to be actually quite similar. About debugging, service workers are easily debuggable, though not on the main thread as you already mentioned.

Re: Server-Sent Events (SSE) Are Underrated

#145

Post by mrngm »

arccy wrote: post #65
SahAssar wrote: post #42

Earlier quoted context omitted.

To do that they need to MITM and tamper with the inner protocol. In my experience this is quite rare. Some MITM proxies analyze the traffic, restrict which ciphers can be used, block non-dns udp (and therefore HTTP/3), but they don't usually downgrade the protocol from HTTP/2 to HTTP/1.

"tamper" sounds much more involved than what they (their implementation) probably do: the proxy decodes the http request, potentially modifies it, and uses the decoded form to send a new request using their client, which only speaks http/1

That is already tampering with the request. It's not simply forwarded to the requested destination, but intercepted, interpreted, and resent... with a different client than the original source.

Re: Server-Sent Events (SSE) Are Underrated

#146

Post by slow_typist »

abnercoimbre wrote: post #137
Tiberium wrote: post #123

Earlier quoted context omitted.

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?

Well if it applied, someone should train a model that tells LLM and human content apart for automated rejection.

Re: Server-Sent Events (SSE) Are Underrated

#148

Post by skue »

RevEng wrote: post #115

OpenAI's own documentation makes note of how difficult it is to work with SSE and to just use their library instead. My team wrote our own parser for these streaming events from an OpenAI compatible LLM server. The streaming format is awful. The double newline block separator also shows up in a bunch of our text, making parsing a nightmare. The "data:" signifier is slightly better, but when working with scientific so…

> I'm happy to have something like SSE but the protocol needs more time to cook.

Just how well done do you like your protocols? SSE has been part of the WHATWG standard for almost 20 years.

Every protocol requires some sort of data encoding. For SSE you need to either restrict yourself to payloads that can never conflict with the message structure (e.g. an enumeration of short strings to indicate different sorts of events), or you need to encode the data.

It sounds like you are trying to send raw, unencoded data and are surprised that it sometimes conflicts with the message structure. Well of course it does! You can’t blame the protocol for that.

Re: Server-Sent Events (SSE) Are Underrated

#149

Post by wlonkly »

I love the format of this. I can tuck it away and whenever I need to think about SSE, refer back to it, ah, okay, now I'm all caught up.

Also, surprised nobody's brought up PointCast[1] yet. Dotcom bubble, or ahead of their time?

(Aside: while looking for a good reference link for Pointcast, I found an All Things Considered episode[2] about it from 1996!)

[1] https://www.ecommerce-digest.com/early-dot-com-failure-case-...

[2] https://www.npr.org/1996/02/13/1042379/pointcast

Re: Server-Sent Events (SSE) Are Underrated

#150

Post by RevEng »

skue wrote: post #148
RevEng wrote: post #115

OpenAI's own documentation makes note of how difficult it is to work with SSE and to just use their library instead. My team wrote our own parser for these streaming events from an OpenAI compatible LLM server. The streaming format is awful. The double newline block separator also shows up in a bunch of our text, making parsing a nightmare. The "data:" signifier is slightly better, but when working with scientific so…

> I'm happy to have something like SSE but the protocol needs more time to cook. Just how well done do you like your protocols? SSE has been part of the WHATWG standard for almost 20 years. Every protocol requires some sort of data encoding. For SSE you need to either restrict yourself to payloads that can never conflict with the message structure (e.g. an enumeration of short strings to indicate different sorts of e…

Every other protocol I've used has a standard way to encode arbitrary data, but especially text data, usually using some kind of escape sequence. SSE does not.

Just because it has been around for a long time does not mean it is well thought out or complete.

Post reply on HN