SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug.
Server-Sent Events: an alternative to WebSockets
61–70 of 266 posts
Re: Server-Sent Events: an alternative to WebSockets
#62I have always preferred SSE to WebSockets. You can do a _lot_ with a minuscule amount of code, and it is great for updating charts and status UIs on the fly without hacking extra ports, server daemons and whatnot.
Re: Server-Sent Events: an alternative to WebSockets
#63The most compatible technique is long polling (with a re-established connection after X seconds if no event). Works suprisingly well in many cases and is not blocket by any proxies.
Re: Server-Sent Events: an alternative to WebSockets
#64Earlier quoted context omitted.
See my comment below: https://news.ycombinator.com/item?id=30313403
Been reading all your comments on this thread (thank you) with interest. Can you recommend some resources for learning SSE in depth?
I would look at my own app-server: https://github.com/tinspin/rupy
It's not the most well documented but it's the smallest implementation while still being one of the most performant so you can learn more than just SSE.
Re: Server-Sent Events: an alternative to WebSockets
#65SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.
6 connections per domain per browser: https://bugs.chromium.org/p/chromium/issues/detail?id=275955
There are some hacks to work around it though.
Re: Server-Sent Events: an alternative to WebSockets
#66I like them, they surprisingly easy to use.. One example where i found it to be not the perfect solution was with a web turn-based game. The SSE was perfect to update gamestate to all clients, but to have great latency from the players point of view whenever the player had to do something, it was via a normal ajax-http call. Eventually I had to switch to uglier websockets and keep connection open. Http-keep-alive was…
You just needed to send a "noop" (no operation) message at regular intervals.
that puts it instantly in the "fired if you ever use it" bin
Re: Server-Sent Events: an alternative to WebSockets
#67Earlier quoted context omitted.
The mistake they did was to assume only one TCP socket should be used; the TCP has it's own head-of-line limitations just like HTTP/1.1 has if you limit the number of sockets (HTTP/1.1 had 2 sockets allowed per client, but Chrome doesn't care...) it's easily solvable by using more sockets but then you get into concurrency problems between the sockets. That said if you, like SSE on HTTP/1.1; use 2 sockets per client (…
The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).
Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push.
Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http://move.rupy.se/file/wheel.jpg
Re: Server-Sent Events: an alternative to WebSockets
#68the biggest drawback with SSE, even when unidirectional comm is sufficient is > SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6). https://ably.com/blog/websockets-vs-sse SharedWorker could be one way to solve this, but lack of Safari support is a blocker, as usual.…
It used to be 2 sockets per client, so now it's 6? Well it's a non-problem, if you need more bandwith than one socket in each direction can provide you have much bigger problems than the connection limit; which you can just ignore.
the problem is multiple tabs. if you have, e.g. a bunch of Grafana dashboards open on multiple screens in different tabs (on same domain), you will exhaust your HTTP connection limit very quickly with SSE.
in most cases this is not a concern, but in some cases it is.
Re: Server-Sent Events: an alternative to WebSockets
#69I have used SSEs extensively, I think they are brilliant and massively underused. The one thing I wish they supported was a binary event data type (mixed in with text events), effectively being able to send in my case image data as an event. The only way to do it currently is as a Base64 string.
Send an event that tells the browser to request the binary image.
Re: Server-Sent Events: an alternative to WebSockets
#70SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.
Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs.
(There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't developed in a vacuum by people who had no idea what they were doing, and it wasn't developed aimlessly or without real world testing. It is used by pretty much all major websites, and they absolutely wouldn't use it if HTTP/1.1 was better... those major websites exist to serve their customers, not to conspiratorially push an agenda of broken technologies that make the customer experience worse.)