▲ | arrowtrench 4 days ago | |
Is local-first bad / more difficult for collaboration because of conflict resolution? (E.g., two users edit the same document when they're offline and then, during syncing, they find that their versions diverge too much for them to be merged cleanly.) If so, isn't it possible to mark certain assets as "undivergable" which would effectively mean that the program would act like a traditional cloud-first type of app for that specific asset? This middle ground could introduce too much complexity and some inconsistency, but it could prove useful in certain cases. | ||
▲ | jonathanstrange 4 days ago | parent [-] | |
Merge conflicts arise just as easily in a cloud-first app than in a local-first app once you go beyond any simple "last edit wins" consistency model (and if you have that model, it's also no problem for local-first). What counts as a conflict depends entirely on the data domain in both cases, and that's the hard part. It's just easier to implement cloud-first because it's just CRUD with a centralized database on a server. It's still extremely hard to reliably connect two apps directly peer to peer without some centralized server as an intermediary and since you need a centralized server anyway and in addition have to do the peer to peer syncing, "local first with syncing" is inherently more complex than just syncing to a master database. But potential merge conflicts are the same in both. |