Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
wa-automate-nodejs
💬 🤖 The most reliable tool for chatbots with advanced features. Be sure to 🌟 this repository for updates!
-
overture
Overture is a powerful JS library for building really slick web applications, with performance at, or surpassing, native apps.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
The data is here: http://fuse.rupy.se/about.html
Under Performance. Per watt the fuse/rupy platform completely crushes all competition because of 2 reasons:
- Event driven protocol design, averages at about 4 messages/player/second (means you cannot do spraying or headshots f.ex. which is another feature in my game design opinion).
- Java's memory model with atomic concurrency which needs a VM and GC (C++ copied that memory model in C++11, but it failed completely because they lack both VM and GC, but that model is still to this day the one C++ uses), you can read more about this here: https://github.com/tinspin/rupy/wiki
You can argue those points are bad arguments, but if you look at performance per watt with some consideration for developer friendlyness, I'm pretty sure in 100 years we will still be coding minimalist JavaSE on the server and vanilla C (compiled with C++ compiler) on the client.
I made the backend for this MMO on SSE over HTTP/1.1:
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.0 to make SSE work well. Actually the HTTP/2.0 TCP head-of-line issue and all the workarounds for that probably make it harder to scale without technical debt.
Around the corner? There seems to be nothing about this in any browser. [0] That would put this what, five years out before it could be used in straightforward fashion? Please be practical.
[0] https://caniuse.com/?search=webtransport
He was likely using a polyfill. It’s definitely not in the spec and there’s an open discussion about trying to get it added: https://github.com/whatwg/html/issues/2177
the 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
also, for websockets, there are various libs that handle auto-reconnnects, e.g. https://github.com/github/stable-socket
My personal WebSockets vs SSE TL;DR goes something like this:
* If you're on HTTP/2, start with SSE
* If you need to send binary data, use 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).
[0]: https://rsocket.io/
[1]: https://github.com/omnistreams/omnistreams-spec
My personal WebSockets vs SSE TL;DR goes something like this:
* If you're on HTTP/2, start with SSE
* If you need to send binary data, use 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).
[0]: https://rsocket.io/
[1]: https://github.com/omnistreams/omnistreams-spec
There's also the Mercure protocol, built on top of Server-Sent Events: https://mercure.rocks/
Yeah, that seems to be the case (confirmed with their little example at https://github.com/mdn/dom-examples/tree/master/server-sent-...). Once the connection is closed you can see things, but that's not particularly useful for debugging!
ESPHome (an easy to use firmware for ESP32 chips) uses SSE to send sensor data to subscribers.
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.
Love your hybrid model via gumroad! I do something similar for my own open-source project
https://github.com/open-wa/wa-automate-nodejs
There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!
It is, however, interesting to note that Fastmail’s webmail doesn’t use EventSource, but instead implements it atop fetch or XMLHttpRequest. An implementation atop XMLHttpRequest was required in the past because of IE, but it still deliberately doesn’t use EventSource; my foggy recollection from a few years ago is that it had to do with control over timeout/disconnect/reconnect, and handling Last-Event-ID, plus maybe skipping browser bugs in some older (now positively ancient and definitely unsupported) browsers. The source for that stuff is the three *EventSource.js files in https://github.com/fastmail/overture/tree/master/source/io.