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

71–80 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#71

Post by kdunglas »

apitman wrote: post #24
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…

The site mentions battery-efficiency specifically. I'm curious what features does Mercure provide in that direction?

SSE/Mercure (as WebSockets) is much battery-efficient than polling (push vs poll, less bandwidth used).

Additionally, on controlled environnements, SSE can use a « push proxy » to wake up the device only when necessary: https://html.spec.whatwg.org/multipage/server-sent-events.ht...

Re: Server-Sent Events (SSE) Are Underrated

#72

Post by dilyevsky »

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’s exactly what they’re doing and it’s still very common in private networks

Re: Server-Sent Events (SSE) Are Underrated

#73

Post by pests »

apitman wrote: post #24
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…

The site mentions battery-efficiency specifically. I'm curious what features does Mercure provide in that direction?

It comes down to all the extra bytes sent and processed (local and remote, and in flight) by long polling. SSE events are small while other methods might require multiple packets and all the needless headers throughout the stack, for example.

Re: Server-Sent Events (SSE) Are Underrated

#75

Post by [deleted] »

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

[deleted]

Re: Server-Sent Events (SSE) Are Underrated

#76

Post by ksajadi »

I'm curious as to how everyone deals with HTTP/2 requirements between the backend servers and the load balancer? By default, HTTP/2 requires TLS which means either no SSL termination at the load balancer or a SSL cert generated per server with a different one for the front end load balancer. This all seems very inefficient.

Re: Server-Sent Events (SSE) Are Underrated

#77

Post by kcb »

ksajadi wrote: post #76

I'm curious as to how everyone deals with HTTP/2 requirements between the backend servers and the load balancer? By default, HTTP/2 requires TLS which means either no SSL termination at the load balancer or a SSL cert generated per server with a different one for the front end load balancer. This all seems very inefficient.

Not sure how widespread this is but AWS load balancers don't validate the backend cert in any way. So I just generate some random self signed cert and use it everywhere.

Re: Server-Sent Events (SSE) Are Underrated

#78

Post by tonyhart7 »

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…

its cool but its in go, do you know other implementation in rust ????

Re: Server-Sent Events (SSE) Are Underrated

#79

Post by ksec »

uncomplexity_ wrote: post #41
hamandcheese wrote: post #39

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 m…

wait let's check this https://news.ycombinator.com/item?id=42511562 at https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... it says "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). The issue has been marked as "Won't fix" i…

Even if they don't change the default 6 open connection. They could have at least made it per tab rather than per site. [1] [2] And I dont understand why this hasn't been done in the past 10 years.

What am I missing?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=906896

[2] https://issues.chromium.org/issues/40329530

Re: Server-Sent Events (SSE) Are Underrated

#80

Post by nhumrich »

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

Http2 is controllable by you, since it's supposed in every browser. So, the way to fix this limitation is to use http2
Post reply on HN