111–120 of 153 posts
https://data-star.dev is a hypermedia-oriented front end library built entirely around the idea of streaming hypermedia responses via SSE. It was developed using Go & NATS as backend technologies, but works with any SSE implementation. Worth checking out if you want to explore SSE and what can be achieved w/it more deeply. Here is an interview with the author: https://www.youtube.com/watch?v=HbTFlUqELVc
https://data-star.dev is a hypermedia-oriented front end library built entirely around the idea of streaming hypermedia responses via SSE. It was developed using Go & NATS as backend technologies, but works with any SSE implementation. Worth checking out if you want to explore SSE and what can be achieved w/it more deeply. Here is an interview with the author: https://www.youtube.com/watch?v=HbTFlUqELVc
Earlier quoted context omitted.
Interesting, hadn't checked at the TCP level. Will need to look into that.
I remembered wrong. In most circumstances a tcp connection will be gracefully terminated by sending a FIN message. The timeout I talked about is on an ACK for a keepalive message. So after x time of not receiving a keepalive message the connection is closed. This handles cases where a connection is ungracefully dropped. All this is done at the kernel level, so at the application level you should be able to just verif…
If anyone knows any library or framework in any language that solves this problem, I'd love to hear about it.
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 guess with WebSockets, if you choose to send messages from the client to the server, then you have some additional work that you wouldn't have with SSE.
The suggestions I've found online for how to deal with the newline issue are to fold together consecutive newlines, but this loses formatting of some documents and otherwise means there is no way to transmit data verbatim. That might be fine for HTML or other text formats where newlines are pretty much optional, but it sucks for other data types.
I'm happy to have something like SSE but the protocol needs more time to cook.
Earlier quoted context omitted.
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 do…
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…
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.
Earlier quoted context omitted.
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, in…
Earlier quoted context omitted.
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.
Can you suggest some resources to learn more about Websocket scaling? Seems like an interesting topic
Ideally it is based on the rate of incoming connections, but so long as you leave enough headroom when doing the stupid simple scaling rule you should be fine. Just ensure new instances don't take too long to start up.
> SSE works seamlessly with existing HTTP infrastructure:
I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, effectively making SSEs useless. I had to use WebSockets instead to get around this limitation with the load balancer.