| > How should we reconcile these changes, if simply allowing either one to take precedence means discarding data from the other? Exactly. This is why Replicache expresses change as high-level operations, like createPost or deletePerson that are application-defined. Replicache doesn't try to automatically merge the effects of concurrent mutations, it just replays the mutations in the same order on each client. It's up to the implementation of the mutation to decide what the correct result is, and that answer can and often does change when the mutation is replayed on top of different states. Because Replicache mutations are atomic, applications can also enforce invariants such as uniqueness or even more complex app-level invariants. Imagine, for example, a calendaring application. An application built with Replicache can enforce the invariant that a room is only booked by one event in one time slice even under concurrent edits, just using normal programmatic validation. It's hard to do this kind of thing with CRDTs or other approaches to automatic merging because the data model knows nothing about the application's constraints. It's a pretty simple-minded system, actually, but our experience is that it is a nice way to think about these problems and provides good results for many types of data, in particular structured data. |