3 ms·
The architecture I have in mind is to use a CRDT of some sort as the data store. (Or OT if you have a centralised server and want to keep complexity down). Then
by josephg 5y ago
The architecture I have in mind is to use a CRDT of some sort as the data store. (Or OT if you have a centralised server and want to keep complexity down). Then make the client smart, like old school apps like OmniFocus. Do concurrent editing via the data layer - so the application only really deals with the local data and hears about updates via the underlying data itself changing.
The data model can be reused across many applications, since there's nothing application specific about it. So we can make standard, interoperable debugging tools, backup tools, viewers, etc.
If you want to interact with the same data from scripts, cron jobs and external services, just have another peer on the network with access to the same set of API methods the application can access. You can already read and write data via that API, and any applications with the data open should see any changes instantly.
Basically, what I'm imagining is pretty similar to a self hosted firebase. Except, ideally, I want a CRDT under the hood so we don't need to send all edits via someone else's computer.