This kind of tool is exactly what I would have needed, instead of the approach I've taken which is a bit kludgy and grass-roots.
By far the most difficult part of it for me was ensuring that the web socket network can heal from outages of any of the clients or the server. E.g. If a client loses connection, how does it regain knowledge of state? If the server dies, what do clients do with state changes they want to upload? Etc. It was really difficult!
Good work :)
So, I played a bit and it appears that if a client is disconnected and changes of the state happens when offline, once connected these changes will be applied to the other client who was having its own changes in the state. So its working on the "last message" basis? Also it seems like it can't detect the offline/online status?
I'm curious because the interesting part of this kind of systems is the way races are handled.
> DriftDB is a real-time data backend that runs on the edge
What does it mean for these backends to be “on the edge”? Do geographically disperse clients connect to different backends? If so are messages synchronized between them? If so what’s the point of them being on the edge?
When you say limitations are a "relatively small number of clients need to share some state over a relatively short period of time," I read in another comment about a dozen or so clients, but what about the time factor? Can it be on the order of hours?
Colyseus has support for persistence as well as matchmaking!
In addition to stateless messaging, it supports durable streams, and optimized API layers on top like key-value, and object storage.
The server also natively supports MQTT 3.1.1.
My brain just exploded with how perfect this DX is! Love it!
What does "on the edge" mean in this context? Can I just run the server part on my own infrastructure? What if I have multiple pods for redundancy, and client web connections might get connected randomly to any of those pods? How would the pods all share state between each other?
Glad there's an alternative.
I think DB in the name is a little misleading due to there being no persistence (I assume?) but that is a small nitpick!
Has anyone experience with it? It seems quite interesting but I need more opinion on what they call "backend sessions"...
Looking forward to seeing how this progresses.
Obv. there's not a cloudflare worker running say an MQTT server over websockets, but you can scope topics with wildcards (https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topi...), replay missed messages on reconnection, last-will-and-testament, ACLs, dynamic topic creation, binary messages etc.
I'm asking as many of these websocket projects seem to use custom protocols rather than anything standard aka interoperable.