4 ms·
If I want to have an app that needs to eventually persist user state to a server but still work well when the user is offline, e.g. a personal vocabulary app th
by toxicFork 4y ago
If I want to have an app that needs to eventually persist user state to a server but still work well when the user is offline, e.g. a personal vocabulary app that can work with multiple devices but also can work when the user is offline, so the user can still define new words manually on both devices, and then when the phone is back online, the state still makes sense in both, should I use CRDT?
- jamil7 4y agoThe article talks about this, in the case where your clients are syncing with a centralised server you don't necessarily need to use CRDTs, and it might be simpler not to.
- dinosaurdynasty 4y agoBasic CRDTs are still useful (idempotency, associativity, and commutativity are powerful mental tools for all distributed systems, even OT) but you can massively simplify the CRDTs if you assume a super-peer (aka centralized server all updates go through). Example: last-write-wins register, which is a (v, t) pair, normally has a merge function of "return the pair with the greatest t (with deterministic tie breaking for same t)", and for a super peer just have v's and "the latest value to hit the server wins".
- preseinger 4y agoIf you have a centralized server there is no reason to use CRDTs, is there?
- dinosaurdynasty 4y agoIt's still very useful mental tool, since a centralized server + clients is still a distributed system. But yeah, you shouldn't use the really complex CRDTs in that case. (And in most cases to be honest.)
- layer8 4y agoThis doesn’t address how changes that were committed offline are merged on the central server once the clients are online again.
- jamil7 4y agoNo but since they’re all getting merged in one place you don’t really need a CRDT for that although you could. That was my point.
- eternalban 4y agoA definitive no is the answer. This complexity is necessary only if others care about your shared state aka vocabulary, and, multiple write ops are being done on same records at the same relative time on different devices. For example, a document editor could use CRDTs without looking silly. A CRDT is an eventually consistent distributed object but all its complexity is there to handle concurrent modifications. In your application, the consistency requirements are pretty weak and easy to meet with a basic client/server architecture with a well defined sync point set on its life-cycle. For example, sync on boot, sync on net-reconnect, etc. Or, you could use a simple P2P protocol so on boot you discover your other connected devices and your apps can shake hand and exchange notes to sync up as they modify their local state: “Hey gang, + “KISS”. “Keep it simple ..”. Use json if you must. Further simple characteristics of this app is that the state ops on your dictionary are commutative (like a CRDT!). On one device you add word “Foo” and on the other you add “Bar”. You do not care (do you?) that you added them in a certain order, so you don’t even have to bother with what is rather difficult to do in a performant manner: maintain a total ordering over the state of the system. (Think sharded ordered-sets..)
- fwip 4y agoThere's a few edge cases that you'd probably need to handle (like adding the same word with two different definitions), but probably few enough that you could do them ad-hoc and punt to the user. ("Hey, merging these two sets failed, here's the conflict, which do you want to keep?") Something fancy like Operational Transforms or CRDT might make your life easier if you find a library that's ergonomic for your use case, but it's definitely not necessary.