I made the backend for this MMO on SSE over HTTP/1.1:<p><a href="https://store.steampowered.com/app/486310/Meadow/" rel="nofollow">https://store.steampowered.com/app/486310/Meadow/</a><p>We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source:<p><a href="https://github.com/tinspin/fuse" rel="nofollow">https://github.com/tinspin/fuse</a><p>You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it harder to scale without technical debt.
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.<p>1. <a href="https://jmap.io/spec-core.html#event-source" rel="nofollow">https://jmap.io/spec-core.html#event-source</a>
We use SSE for our APIs Server Events feature <a href="https://docs.servicestack.net/server-events" rel="nofollow">https://docs.servicestack.net/server-events</a> with C#, JS/TypeScript and Java high-level clients.<p>It's a beautifully simple & elegant lightweight push events option that works over standard HTTP, the main gotcha for maintaining long-lived connections is that server/clients should implement their own heartbeat to be able to detect & auto reconnect failed connections which was the only reliable way we've found to detect & resolve broken connections.
My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better.<p>Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.
the biggest drawback with SSE, even when unidirectional comm is sufficient is<p>> 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).<p><a href="https://ably.com/blog/websockets-vs-sse" rel="nofollow">https://ably.com/blog/websockets-vs-sse</a><p>SharedWorker could be one way to solve this, but lack of Safari support is a blocker, as usual. <a href="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...</a><p>also, for websockets, there are various libs that handle auto-reconnnects<p><a href="https://github.com/github/stable-socket" rel="nofollow">https://github.com/github/stable-socket</a><p><a href="https://github.com/joewalnes/reconnecting-websocket" rel="nofollow">https://github.com/joewalnes/reconnecting-websocket</a><p><a href="https://dev.to/jeroendk/how-to-implement-a-random-exponential-backoff-algorithm-in-javascript-18n6" rel="nofollow">https://dev.to/jeroendk/how-to-implement-a-random-exponentia...</a>
We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case.<p>First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than 1000ms latency, with WebSocket, even though we faced connections drops, client received data on time. But in SSE, it took many seconds to reach some clients, since the data was time critical, WebSocket seemed much easier to scale for our purposes. Another issue was that SSE is like an idea you get done with HTTP APIs, so it doesn't have much support around it like WS. Things like rooms, clientIds etc needed to be managed manually, which was also a quite big task by itself. And a few other minor reasons too combined made us switch back to WS.<p>I think SSE will suit much better for connections where bulk broadcast is less, like in shared docs editing, showing stuff like "1234 users is watching this product" etc. And keep in mind that all this is coming from a mediocre full stack developer with 3 YOE only, so take it with a grain of salt.
I like them, they surprisingly easy to use..<p>One example where i found it to be not the <i>perfect</i> solution was with a web turn-based game.<p>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.<p>Eventually I had to switch to <i>uglier</i> websockets and keep connection open.<p>Http-keep-alive was that reliable.
SSEs 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.
Did research on SSE a short while ago. Found out that the mimetype "text/event-stream" was blocked by a couple of anti-virus products. So that was a no-go for us.
I’m a huge fan of SSE. In the first chapter of my book Fullstack Node.js I use it for the real-time chat example because it requires almost zero setup. I’ve also been using SSE on <a href="https://rambly.app" rel="nofollow">https://rambly.app</a> to handle all the WebRTC signaling so that clients can find new peers. Works great.
This is really interesting! I wonder why it never really took off, whereas websockets via Socket.IO/Engine.io did.<p>At NodeBB, we ended up relying on websockets for almost everything, which was a mistake. We were using it for simple call-and-response actions, where a proper RESTful API would've been a better (more scalable, better supported, etc.) solution.<p>In the end, we migrated a large part of our existing socket.io implementation to use plain REST. SSE sounds like the second part of that solution, so we can ditch socket.io completely if we really wanted to.<p>Very cool!
I have used SSEs extensively, I think they are brilliant and massively underused.<p>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.
Very easy to implement - still using code I wrote 8 years ago, which is like 20 lines client and server, choosing it at the time over ws.<p>Essentially just new EventSource(), text/event-stream header, and keep conn open. Zero dependencies in browser and nodejs. Needs no separate auth.
Personally i use mqtt over websockets, paho[0] is a good js library. It support last will for dc's and the message queue design makes it easy to think of and debug. There also a lot of mq brokers that will scale well.<p>[0]: <a href="https://www.eclipse.org/paho/index.php?page=clients/js/index.php" rel="nofollow">https://www.eclipse.org/paho/index.php?page=clients/js/index...</a>
ESPHome (an easy to use firmware for ESP32 chips) uses SSE to send sensor data to subscribers.<p>I made use of that in Lunar (<a href="https://lunar.fyi/#sensor" rel="nofollow">https://lunar.fyi/#sensor</a>) to be able to adjust monitor brightness based on ambient light readings from an external wireless sensor.<p>At first it felt weird that I have to wait for responses instead of polling with requests myself, but the ESP is not a very powerful chip and making one HTTP request every second would have been too much.<p>SSE also allows the sensor to compare previous readings and only send data when something changed, which removes some of the complexity with debouncing in the app code.
A complete SSE example in 25 lines on Deno Deploy: <a href="https://dash.deno.com/playground/server-sent-events" rel="nofollow">https://dash.deno.com/playground/server-sent-events</a>
I had the pleasure of being forced to use in SSE due to working with a proxy that didn't support websockets.<p>Personally I think it's a great solution for longer running tasks like "Export your data to CSV" when the client just needs to get an update that it's done and here's the url to download it.
I can’t find any downsides of SSE presented. My experience is that they’re nice in theory but the devils in the details. The biggest issue being that you basically need http/2 to make them practical.
The extra setup step for websocket should not be required: <a href="https://caddyserver.com/docs/v2-upgrade#proxy" rel="nofollow">https://caddyserver.com/docs/v2-upgrade#proxy</a><p>I also had no problems with HAProxy, it worked with websockets without any issues or extra handling.
This is why I really really like Hotwire Turbo[0] which is a back-end agnostic way to do fast and partial HTML based page updates over HTTP and it optionally supports broadcasting events with WebSockets (or SSE[1]) only when it makes sense.<p>So many alternatives to Hotwire want to use WebSockets for everything, even for serving HTML from a page transition that's not broadcast to anyone. I share the same sentiment as the author in that WebSockets have real pitfalls and I'd go even further and say unless used tastefully and sparingly they break the whole ethos of the web.<p>HTTP is a rock solid protocol and super optimized / well known and easy to scale since it's stateless. I hate the idea of going to a site where after it loads, every little component of the page is updated live under my feet. The web is about giving users control. I think the idea of push based updates like showing notifications and other minor updates are great when used in moderation but SSE can do this. I don't like the direction of some frameworks around wanting to broadcast everything and use WebSockets to serve HTML to 1 client.<p>I hope in the future Hotwire Turbo alternatives seriously consider using HTTP and SSE as an official transport layer.<p>[0]: <a href="https://hotwired.dev/" rel="nofollow">https://hotwired.dev/</a><p>[1]: <a href="https://twitter.com/dhh/status/1346095619597889536?lang=en" rel="nofollow">https://twitter.com/dhh/status/1346095619597889536?lang=en</a>
One problem I had with WebSockets is you can not set custom HTTP headers when opening the connection. I wanted to implement a JWT based authentication in my backend and had to pass the token either as a query parameter or in a cookie.<p>Anyone knows the rationale behind this limitation?
---
WebSockets cannot benefit from any HTTP feature. That is:<p><pre><code> No support for compression
No support for HTTP/2 multiplexing
Potential issues with proxies
No protection from Cross-Site Hijacking</code></pre>
---<p>Is that true? The web never cease to amaze.
Is it worth upgrading a long polling solution to SSE? Would I see much benefit?<p>What I mean by that is client sends request, server responds in up to 2 minutes with result or a try again flag. Either way client resends request and then uses response data if provided.
The 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.
With WebTransport around the corner I don't think is worth the time investing in learning a, what seems to me, obsolete technology. I can understand it for already big projects working with SSE that don't want to pay the cost of upgrading/changing but for anything new I cannot be bothered since Websockets work good enough for my use cases.<p>What worries me though is the trend of dismissal of newer technologies as being useless or bad and the resistance to change.
One issue with SSE is that dumb enterprise middleboxes and Windows antivirus software break them :(<p>They'll try to read the entire stream to completion and will hang forever.
This seems fairly cool, and I appreciate the write up, but god I hate it so much when people write code samples that try and be fancy and use non-code-characters in their code samples. Clarity is much more important then aesthetics when it comes to code examples, if Im trying to understand something I've never seen before, having a bunch of extra non-existant symbols does not help.
Can someone give a brief summary of how this differs from long polling. It looks very similar except it has a small layer of formalized event/data/id structure on top? Are there any differences in the lower connection layers, or any added support by browsers and proxies given some new headers?<p>What are the benefits of SSE vs long polling?
> RFC 8441, released on September 2018, tries to fix this limitation by adding support for “Bootstrapping WebSockets with HTTP/2”. It has been implemented in Firefox and Chrome. However, as far as I know, no major reverse-proxy implements it.<p>HAProxy supports RFC 8441 automatically. It's possible to disable it, because support in clients tends to be buggy-ish: <a href="https://cbonte.github.io/haproxy-dconv/2.4/configuration.html#3.1-h2-workaround-bogus-websocket-clients" rel="nofollow">https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...</a><p>Generally I can second recommendation of using SSE / long running response streams over WebSockets for the same reasons as the article.
I 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.
I have investigated SSE for <a href="https://fiction.live" rel="nofollow">https://fiction.live</a> a few years back but stayed with websockets. Maybe it's time for another look. I pay around $300 a month for the websocket server, it's probably not worth it yet to try to optimize that but if we keep growing at this rate it may soon be.
I usually use SSEs for personal projects because they are way more simple than WebSockets (not that those aren't also simple) and most of the time my web apps just need to listen for something coming from the server and not bidirectional communication.
EventSource has been around for eons, and is what the precursor to webpack-dev-server used for HMR events. It had the advantage of supporting ancient browsers since the spec has been around a long time and even supported by oldIE.
For starlette/fastapi there is a battle tested lib: <a href="https://github.com/sysid/sse-starlette" rel="nofollow">https://github.com/sysid/sse-starlette</a>
I've found hasses (<a href="https://github.com/hyper-prog/hasses" rel="nofollow">https://github.com/hyper-prog/hasses</a>) a really nice SSE server.<p>Good performance, easy to use, easy to integrate.
I think SSE might make a lot of sense for Serverless workloads? You don't have to worry about running a websocket server, any serverless host with HTTP support will do. Long-polling might be costlier though?
this is what i have been telling people for years, but its hard to get the word out there. usually every dev just reflexes without thinking to websockets when anything realtime or push related comes up.
Solid has a great solution for this: <a href="https://solid.github.io/notifications/protocol" rel="nofollow">https://solid.github.io/notifications/protocol</a>
There's also the Mercure protocol, built on top of Server-Sent Events: <a href="https://mercure.rocks/" rel="nofollow">https://mercure.rocks/</a>
My personal browser streaming TL;DR goes something like this:<p>* Start with SSE<p>* If you need to send binary data, use long polling or WebSockets<p>* If you need fast bidi streaming, use WebSockets<p>* If you need backpressure and multiplexing for WebSockets, use RSocket or omnistreams[1] (one of my projects).<p>* Make sure you account for SSE browser connection limits, preferably by minimizing the number of streams needed, or by using HTTP/2 (mind head-of-line blocking) or splitting your HTTP/1.1 backend across multiple domains and doing round-robin on the frontend.<p>[0]: <a href="https://rsocket.io/" rel="nofollow">https://rsocket.io/</a><p>[1]: <a href="https://github.com/omnistreams/omnistreams-spec" rel="nofollow">https://github.com/omnistreams/omnistreams-spec</a>
I tried out server side events, but they are still quite troubling with the lack of headers and cookies. I remember I needed some polyfill version which gave more issues.
So do I understand correctly that when using SSE, the login cookie of the user is not automatically sent with the SSE request like it is with all normal HTTP requests? And I have to redo auth somehow?