Live data from Hacker News

Server-Sent Events (SSE) Are Underrated

igorstechnoclub.com

81–90 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#81
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.

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.

Re: Server-Sent Events (SSE) Are Underrated

#82
post #10

> Perceived Limitations: The unidirectional nature might seem restrictive, though it's often sufficient for many use cases For my use cases the main limitations of SSE are: 1. Text-only, so if you want to do binary you need to do something like base64 2. Browser connection limits for HTTP/1.1, ie you can only have ~6 connections per domain[0] Connection limits aren't a problem as long as you use HTTP/2+. Even so, I d…

ReadableStream appears to be SSE without any defined standards for chunk separation. In practice, how is it any different from using SSE? It appears to use the same concept.

Re: Server-Sent Events (SSE) Are Underrated

#83
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.

Re: Server-Sent Events (SSE) Are Underrated

#84
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.

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?

Re: Server-Sent Events (SSE) Are Underrated

#85
post #70

Earlier quoted context omitted.

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.

I've scaled websockets before, it isn't that hard.

You need to scale up before your servers become overloaded, and basically new connections go north to the newly brought up server. It is a different mentality than scaling stateless services but it isn't super duper hard.

Re: Server-Sent Events (SSE) Are Underrated

#87
post #25

Earlier quoted context omitted.

That might very well be but the future is not today.

But why add it to HTTP/3 at all? HTTP/1.1 hijacking is a pretty simple process. I suspect HTTP/3 would be significantly more complicated. I'm not sure that effort is worth it when WebTransport will make it obselete.

It was added to HTTP/2 as well and there is an RFC. (Though a lot of servers don’t support it even on HTTP/2)

My point is mostly that SSE works well and is supported and that has A meaningful benefit today.

Re: Server-Sent Events (SSE) Are Underrated

#88
post #26

Earlier quoted context omitted.

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?

Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.

> The HTTP/1.1 spec actually recommends limited to 2 connections per domain.

This is no longer true.

From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4):

> Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.

Re: Server-Sent Events (SSE) Are Underrated

#89
post #26

Earlier quoted context omitted.

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?

Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.

Because you're supposed to use a single connection with HTTP Pipelining for all your ressources [1]

When index.html loads 4 CSS and 5 JS : 10 ressources in HTTP 1.0 needed 10 connections, with 10 TLS negociations (unless one ressource loaded fast and you could reuse it's released connection)

With HTTP1.1 Pipelining you open only one connection, including a single TLS nego, and ask 10 ressources.

Why not only 1 per domain so ? IIRC it's because the 1st ressource index.html may take a lot of Time to complete and well race conditions suggest you use another one that the 'main thread' more or less. So basically 2 are sufficient.

[1] https://en.m.wikipedia.org/wiki/HTTP_pipelining

Re: Server-Sent Events (SSE) Are Underrated

#90
Finding use cases for SSE and reading about others doing the same brings me great joy. Very easy to set up -- you just set 2 or 3 response headers and off you go.

I have a hard time imagining the tech's limits outside of testing scenarios so some of the examples brought up here are interesting

Post reply on HN