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."
Conversation
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!
1
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
Yes, Replicache's requirements of underlying storage is a transactional kv store, so pretty easy to adapt to SQLite.
For incrementally syncing large storage:
2
1
Nice! I have native LevelDB bindings for RN, which would probably be even better if we're just looking for a KV store.
I have to remember what the transactional semantics are for LevelDB. Replicache requires actual isolation/rollbacks of multikey writes.
1
Ah, yes, LDB doesn't qualify then.