dfahlander/Dexie.js

Conflict-free sync

dfahlander asked for this feature about 4 years ago — 3 comments

dfahlander commented about 4 years ago Admin

Current Status

Current version of dexie-syncable support Eventual consistency by automatically resolves conflicts using last writer wins. This simplifies a lot for 90% cases such as updating a property of an object, adding object or deleting objects. We currently have nothing to offer for the few cases where conflicts could break consistency (like updating an array property, or for example a counter) except than putting the hard work on the application developer to implement some kind of CRDT types or solving it in another custom way. PouchDB has the option to provide a custom conflict handler for those cases, but as I have understood, that doesn't solve the whole issue either. It also puts the burden on to the app developer.

Strong-Eventual Consistency / Conflict-free sync

A lot of research has been made about Conflict-free replication data. We could allow a super-simple way to accomplish conflict-free replication without the requirement to use state-based CRDT types. What we need is a server-side implementation of the Dexie API along with a framework for decorating methods to become conflict-free database operations. The idea is this:

  • Application Developer encapsulates database-facing code in a class (a service)
  • Each method can optionally be decorated for conflict-free replication.
  • When called, the decorator generates an entry in the change log about the operation and the parameters given to it (rather than just registering CREATE/UPDATE/DELETEs). When changes reach the server, it executes the same operation using the same parameters. This is possible only if the server can lookup the same code to execute. The method could be identified by Class name + "." + method name (ny default). Server also need to support transactions (as indexedDB does).

When implementing this, we must not forget a common requirement of multi-tenancy support on the server. An ideal solution is a server-implementation of the Dexie API that also maintains access control, only replicates data that the user has access to, and only allows queries on data that the user has access to. This is not part of this feature request, but I mention it so that it could be brought up when designing a server with Dexie API.

| acarl commented almost 4 years ago

This would have some great applications for offline first mobile apps where data is shared between users. I really appreciate you pointed out the need for multi-tenancy as well.

SimonBiggs commented almost 2 years ago

Awesome! Simply an awesome idea right there. :)

Join the discussion!

Sign-in with GitHub to comment