by tyrion on 2/12/22, 2:05 PM with 263 comments
by bullen on 2/12/22, 3:26 PM
https://store.steampowered.com/app/486310/Meadow/
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:
https://github.com/tinspin/fuse
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.
by mmcclimon on 2/12/22, 4:38 PM
by mythz on 2/12/22, 4:16 PM
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.
by szastamasta on 2/12/22, 3:59 PM
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.
by leeoniya on 2/12/22, 4:23 PM
> 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. https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...
also, for websockets, there are various libs that handle auto-reconnnects
https://github.com/github/stable-socket
https://github.com/joewalnes/reconnecting-websocket
https://dev.to/jeroendk/how-to-implement-a-random-exponentia...
by hishamp on 2/12/22, 10:05 PM
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.
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.
by rawoke083600 on 2/12/22, 3:17 PM
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 that reliable.
by kreetx on 2/12/22, 4:14 PM
by mmzeeman on 2/12/22, 3:54 PM
by foxbarrington on 2/12/22, 3:47 PM
by julianlam on 2/12/22, 6:18 PM
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.
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.
Very cool!
by samwillis on 2/12/22, 3:39 PM
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.
by dpweb on 2/12/22, 3:34 PM
Essentially just new EventSource(), text/event-stream header, and keep conn open. Zero dependencies in browser and nodejs. Needs no separate auth.
by oneweekwonder on 2/12/22, 3:33 PM
[0]: https://www.eclipse.org/paho/index.php?page=clients/js/index...
by alin23 on 2/12/22, 10:43 PM
I made use of that in Lunar (https://lunar.fyi/#sensor) to be able to adjust monitor brightness based on ambient light readings from an external wireless sensor.
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.
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.
by rough-sea on 2/12/22, 7:16 PM
by waylandsmithers on 2/12/22, 6:17 PM
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.
by sb8244 on 2/12/22, 3:09 PM
by U1F984 on 2/12/22, 10:44 PM
I also had no problems with HAProxy, it worked with websockets without any issues or extra handling.
by nickjj on 2/12/22, 5:06 PM
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.
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.
I hope in the future Hotwire Turbo alternatives seriously consider using HTTP and SSE as an official transport layer.
[1]: https://twitter.com/dhh/status/1346095619597889536?lang=en
by ponytech on 2/12/22, 9:59 PM
Anyone knows the rationale behind this limitation?
by goodpoint on 2/12/22, 3:08 PM
No support for compression
No support for HTTP/2 multiplexing
Potential issues with proxies
No protection from Cross-Site HijackingIs that true? The web never cease to amaze.
by quickthrower2 on 2/12/22, 4:26 PM
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.
by havkom on 2/12/22, 4:40 PM
by laerus on 2/12/22, 7:38 PM
What worries me though is the trend of dismissal of newer technologies as being useless or bad and the resistance to change.
by lima on 2/12/22, 3:25 PM
They'll try to read the entire stream to completion and will hang forever.
by wedn3sday on 2/12/22, 6:36 PM
by Too on 2/12/22, 5:45 PM
What are the benefits of SSE vs long polling?
by TimWolla on 2/12/22, 5:45 PM
HAProxy supports RFC 8441 automatically. It's possible to disable it, because support in clients tends to be buggy-ish: https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...
Generally I can second recommendation of using SSE / long running response streams over WebSockets for the same reasons as the article.
by rcarmo on 2/12/22, 4:39 PM
by KaoruAoiShiho on 2/12/22, 6:01 PM
by tgv on 2/12/22, 5:48 PM
by llacb47 on 2/12/22, 3:30 PM
by ravenstine on 2/12/22, 3:45 PM
by andrew_ on 2/13/22, 1:00 AM
by sysid on 2/25/22, 8:59 PM
by mterron on 2/13/22, 2:49 AM
Good performance, easy to use, easy to integrate.
by captn3m0 on 2/12/22, 4:22 PM
by jFriedensreich on 2/12/22, 4:27 PM
by gibsonf1 on 2/12/22, 7:36 PM
by pbowyer on 2/12/22, 8:44 PM
by beebeepka on 2/12/22, 3:20 PM
by jshen on 2/12/22, 10:52 PM
by njx on 2/12/22, 7:37 PM
by pictur on 2/12/22, 3:16 PM
by anderspitman on 2/12/22, 7:07 PM
* Start with SSE
* If you need to send binary data, use long polling or WebSockets
* If you need fast bidi streaming, use WebSockets
* If you need backpressure and multiplexing for WebSockets, use RSocket or omnistreams[1] (one of my projects).
* 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.
[0]: https://rsocket.io/
by whazor on 2/12/22, 3:02 PM
by axiosgunnar on 2/12/22, 3:45 PM
by The_rationalist on 2/12/22, 4:49 PM