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

61–70 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#61

Post by nchmy »

apitman wrote: post #29
schmichael wrote: post #19

I’ve never understood the use of SSE over ndjson. Builtin browser support for SSE might be nice, but it seems fairly easy to handle ndjson? For non-browser consumers ndjson is almost assuredly easier to handle. ndjson works over any transport from HTTP/0.9 to HTTP/3 to raw TCP or unix sockets or any reliable transport protocol.

Manually streaming a XHR and parsing the messages is significantly more work, and you lose the built-in browser API. But if you use a fetch ReadableStream with TLV messages I'm sold.

Here's SSE with fetch and streams https://github.com/rexxars/eventsource-client

Re: Server-Sent Events (SSE) Are Underrated

#62

Post by nchmy »

ramon156 wrote: post #3

They're underrated when they work™ Currently at work I'm having issues because - Auth between an embedded app and javascript's EventSource is not working, so I have to resort to a Microsoft package which doesn't always work. - Not every tunnel is fond of keep-alive (Cloudflare), so I had to switch to ngrok (until I found out they have a limit of 20k requests). I know this isn't the protocol's fault, and I'm sure ther…

Try this sse client https://github.com/rexxars/eventsource-client

Re: Server-Sent Events (SSE) Are Underrated

#63

Post by giantrobot »

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?

Because 30 years ago server processes often (enough) used inetd or served a request with a forked process. A browser hitting a server with a bunch of connections, especially over slow network links where the connection would be long lived, could swamp a server. Process launches were expensive and could use a lot of memory.

While server capacity in every dimension has increased the low connection count for browsers has remained. But even today it's still a bit of a courtesy to not spam a server with a hundred simultaneous connections. If the server implicitly supports tons of connects with HTTP/2 support that's one thing but it's not polite to abuse HTTP/1.1 servers.

Re: Server-Sent Events (SSE) Are Underrated

#64

Post by toomim »

apitman wrote: post #11
k__ wrote: post #9

Earlier quoted context omitted.

And over HTTP/2 and 3 they are efficient?

HTTP/2+ only uses a single transport connection (TCP or QUIC) per server, and multiplexes over that. So there's essentially no practical limit.

Except that browsers add a limit of ~100 connections even with HTTP/2, for no apparently good reason.

Re: Server-Sent Events (SSE) Are Underrated

#65

Post by arccy »

SahAssar wrote: post #42
jiggawatts wrote: post #32

Earlier quoted context omitted.

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

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

Re: Server-Sent Events (SSE) Are Underrated

#66

Post by nikeee »

raggi wrote: post #50
jesprenj wrote: post #37

Earlier quoted context omitted.

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.

This, it works well in a service worker for example.

How does this work with a service worker? I've only managed to do this via SharedWorker (which is not available on Chrome on Android).

Re: Server-Sent Events (SSE) Are Underrated

#67

Post by Dren95 »

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…

Cool didn’t know this. I used a similar solution called Centrifugo for a while. It allows you to choose which transport to use (ws, sse, others)

https://github.com/centrifugal/centrifugo

Re: Server-Sent Events (SSE) Are Underrated

#68

Post by geoffeg »

SahAssar wrote: post #42
jiggawatts wrote: post #32

Earlier quoted context omitted.

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

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.

That hasn't been my experience at large corporations. They usually have a corporate proxy which only speaks HTTP 1.1, intercepts all HTTPS, and doesn't support websockets (unless you ask for an exception) and other more modern HTTP features.

Re: Server-Sent Events (SSE) Are Underrated

#69

Post by virtue3 »

loloquwowndueo wrote: post #44
sabareesh wrote: post #31

Earlier quoted context omitted.

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

Then why not do it every 59 seconds :)

You’d probably want to do it every 29 seconds in case a ping fails to send/deliver.

Re: Server-Sent Events (SSE) Are Underrated

#70

Post by virtue3 »

mardifoufs wrote: post #58
robocat wrote: post #51

Earlier quoted context omitted.

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?

From what I understand websockets are great until you have to load balance them. And then you learn why they aren’t so great.
Post reply on HN