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
Replying to
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
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
Replying to
do you think there's value in non-syncable, non-collaborative "local-first" ? or where maybe those come from just working with git/github instead of hard to perfect models?
1
1
Yeah, definitely. In fact, I tried hard to design a format which could just be synced as dumb flat files without constant conflicts. But in practice, any app which needs database-like features (querying, indexing) will find this quite difficult.
2
7
Show replies
Replying to
It’s really difficult. I’ve had success applying event sourcing to the problem, but schema evolution is a pain and it means my data model takes up a lot of my complexity budget
1
3
Yeah, I'm using event sourcing on a custom transport/storage system now, and it's eating up *way* too much complexity.
3
1
Show replies
