CODEWITHSUNDEEP
synchronizationcouchdbreplicationpouchdb
Mehrdad Shokri
Mehrdad Shokri

Reputation: 2134

CouchDB data synchronization

I'm developing a TODO app for myself. It has to be offline first so data synchronization became a problem soon. As to my searches, CouchDB does data sync (replication) very well but I'm having some confusion here.
First of all, I'm using Flutter and Dart programming language and there isn't any couch client on Dart. For javascript, there is PouchDB which apparently makes data sync with remote database automatic (Am I right?) as far as I know I should be good to go without any third party library since CouchDB comes with native HTTP API, I can just store user data as a JSON file and just sync it with CouchDB server as a document (Am I right?)
Another confusion for me is that should user data be stored as a document or should I create 1 database per user(In other words does couch syncs database or document?) It also raises authorizations. A user which has access to a database has access to all documents. I want to restrict each user to its documents without placing another API between couch and end-user application.

Upvotes: 4

Views: 3385

Answers (1)

lossleader
lossleader

Reputation: 13495

A primary benefit of pouchdb is having local databases that have APIs like couchdb but are present even while offline, etc. So if you were using pouchdb and want to work offline you would almost certainly want per user dbs on couchdb and to do pouchdb <-> couchdb syncing, etc. But you can't use pouchdb without JS and depending on it in a webview, etc, would largely undermine the benefit of compiling to native code instead of a webview based app.

Using HTTP APIs directly and storing a local document, it is probably simpler to start with each user storing a few simple things as additional JSON on their own user document in _users. You can always add per-user dbs later. The _users database is a little bit special in that it gives each user read access to their own document without having to give them access to other user docs and relies on a validation design document to protect important fields while otherwise letting them edit their data.

In such a scenerio, the client keeps a copy of the users own document locally that it needs to sync back to the server when it has networking. There are of course conflict possibilities for a user with multiple devices, and they can be resolved either by the client itself comparing local and server versions or with the help of update design documents on the server.

Starting from each user having their private data in their own _users doc, one can still build dbs for groups of users where all users in the group share read access to all documents but can only update ones they created. A per user db is really only a special case of such a database, where the group has been reduced to only one member.

Upvotes: 3

Related Questions