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
Conversation
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.
1
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.