It's astonishing to me how difficult it (still) is to design a syncable local-first data model.
I keep thinking I've found a decent way, then realizing its flaws, then despondently noticing that the flaws were already discussed in Ink & Switch's article: inkandswitch.com/local-first.ht
Conversation
Arguably things are even worse than discussed in that article. Take Firebase, for instance: it implements offline caching, but that's very different from sync. You have to design a whole replication strategy on top to get something like "a synced file format."
1
20
CouchDB seems like the closest solution, if you can design a conflict-free model. But I spent the last week getting into the details of actually operating a multi-user service, and I am now quite thoroughly spooked!
8
30
At Quip, we wrote data to a local leveldb bundled with native apps and synced in background using a checksumming mechanism. We had a model layer handled data loading / live updates / mutations & wrote to leveldb on native and sent api requests on web. See
2
5
1
4
Thanks - Replicache is actually a team effort with and Fritz. I'm just a spokesman here :).
- you can join us in discord.replicache.dev - happy to talk about sync anytime :).
1
2
PS - our design doc is open source if you'd like to use that as inspiration: doc.replicache.dev/design.
2
3
Boy, this looks like a really nice design. Alas I can't adopt directly because I have ReactNative targets (no WASM), but I'll certainly learn from this design!
Aw, alright. For RN our plan is to (eventually) compile the Rust to native.
1
2
Sounds like a good plan! I guess you'll need a pluggable persistence model for the client, too.
One other wondering: how does the pull endpoint work when initially replicating large stores, too large to fit in a single response?
1
Show replies