Our great sponsors
-
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.
-
-
-
-
-
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.
-
Mercure
🪽 An open, easy, fast, reliable and battery-efficient solution for real-time communications
-
-
wstunnel
Tunnel all your traffic over Websocket or HTTP2 - Bypass firewalls/DPI - Static binary available
-
You have two sockets, one eternal response with transfer-encoding: chunked, which is basically hex_length\r\n\r\n\r\n over and over again, so very compact.
On the browser to server it gets a bit heavier because you need GET /path?data= HTTP/1.1\r\nHost: kinda.verbose.com\r\n\r\n and then each request gets a response that can be either zero so 200 OK\r\nContent-Length: 0\r\n\r\n or contain a sync. response. It looks bad but trust me that verbosity is a rounding error when it comes to the real bottleneck which is CPU concurrent atomic parrallelism, and for that you basically need to use Java:
https://github.com/tinspin/rupy/wiki (Most people disagree but the VM + GC and Javas memory model allows for atomic shared memory like none other, not even C/C++ can compete because you need a VM with GC to make that memory model work, they tried to copy it into C++11 and that was a faceplant of epic proportions that is still C++ memory model).
CRDT solve a part of your problem, and an important consideration is whether or not you want off-line editing. If you don't need off-line editing, then a WebSocket can do it.
I'm actually using my project to build a collaborative IDE (designer like Figma): http://www.adama-lang.org/
I'm going to be launching it as a SaaS soon so people can spin up a new back-end without managing an infrastructure.
If it's streaming data like dashboard statistics the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md
Only Chrome so far it seems. Firefox's position:
> We are generally in support of a mechanism that addresses the use cases implied by this solution document. While major questions remain open at this time -- notably, multiplexing, the API surface, and available statistics -- we think that prototyping the proposed solution as details become more firm would be worthwhile. We would like see the new WebSocketStream and WebTransport stream APIs to be developed in concert with each other, so as to share as much design as possible.
https://mozilla.github.io/standards-positions/
Unclear what the WebKit (Safari) folks think, based on https://lists.webkit.org/pipermail/webkit-dev/2021-September... that has no replies.
Microsoft is just doing whatever Chrome is doing with Edge, so I guess it'll appear there sooner or later, but can't find any public information.
Bit early to start using WebTransport seems to be the conclusion.
I wrote a document explaining how to implement your own web socket service: https://github.com/prettydiff/wisdom/blob/master/websocket_s...
Implementing your own service logic is incredibly helpful in the cases where you have multiple sockets to manage and custom logic associated with identity, reestablishment, custom data handling, and so forth. There are features in the protocol that aren't used in the browser, for example, and allow for custom scaling.
Here are my learnings about web sockets:
* They are session oriented so that means both end points have to agree to connect. That mitigates many security risks associated with HTTP traffic.
* Web socket messages cannot be interleaved. In 99% of cases this isn't an issue, because control frames unrelated to a web socket message can occur anywhere without interruption. This becomes a problem if you are transfer a large file that takes a substantial amount of transfer time. All other messages must wait in a queue, which means long delayed microservice status updates or you just break things.
* Web sockets are so much faster to process than HTTP. A web socket is primitive. There is no roundtrip (request/response), no headers, and no additional negotiation. I reduced some test automation in my personal application from 45 seconds to 7 seconds by fully converting from HTTP to web sockets for messaging.
* Reliance on web sockets simplifies so much of a service oriented application. I used to rely upon callbacks to HTTP responses to verify message completion and perform next step actions in an application. Instead I am switching to specific messaging for everything. A response is a specific message when the responding machine is ready. This eliminates response timeouts, flattens the architecture, and eases service testing by moving all messaging concerns to a single listener as opposed to listening for responses versus requests from other machines.
* Since web sockets are session oriented they are potentially more fragile than HTTP. If the pipe drops you have to reestablish the connection before sending/receiving service messages.
I made a document editing demo here: https://github.com/fanout/editor
It uses operational transformations to manage conflicts, and it saves the data in MySQL. Technically any Django DB backend will work for storage, but the public demo instance uses MySQL.
One of the reasons I made this thing was to show that realtime apps don't need to require heavy frameworks or unusual databases. And it loads super fast.
I don't think you need Raft if you have a central database storing the document. You could also consider using CRDTs instead of OT, which may be more powerful but also more challenging to develop.
2. Edtech - we have numerous customers using us to drive live classroom environments, think shared white boards, collaborative tests, presence, teacher engagement. You may have used Codewars in the past, that uses Ably under the hood for example, https://www.codewars.com/.
I built omnistreams[0] primarily because of the lack of backpressure in browser WebSockets (lots of background information in that README). It's what fibridge[1] is built on. We've been using it in production for over 2 years, but I never ended up trying to push omnistreams as a thing. I believe the Rust implementation is actually behind the spec a bit, and the spec itself probably needs some work.
At the end of the day I think RSocket is probably the way to go for most people, though the simplicity of omnistreams is still appealing to me.
[0]: https://github.com/omnistreams/omnistreams-spec
[1]: https://iobio.io/2019/06/12/introducing-fibridge/
There are tools to tunnel all your traffic over websockets kind of like a VPN, for example: https://github.com/erebe/wstunnel This would be an easy way to get access to web content blocked by corporate policy, expose internal services to the outside world, or even exfiltrate a bunch of internal data somewhere else.
