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!
Replying to
I've noticed that a lot of modern solutions to this problem assume that it's viable to read the entire data store from disk into memory on load (and, often, write the entire thing on save)—which I guess is a nice simplifying assumption… but quite limiting!
1
25
Both new to me, thanks—will read up.
2
Show replies
thanks for the ping James.
Andy — is my cofounder & creator of the #WebNativeFileSystem link I just shared with you ;)
1
Replying to
Did you consider a eventsourced system ? Pushing only the changes around may give some (eventual) consistency.
1
Yep, that's what I do now, but it's still consuming a huge amount of complexity.
1
1
Show replies
Replying to
I was reading through the article and i was thinking… exporting to text isn’t enough! We need an option to export to clay for true preservation.
Replying to
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
Show replies