couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronan Jouchet <>
Subject Adding a front layer to Couch and sacrificing sync (a reaction to "PouchDB & CouchDB - An interview with Nolan Lawson")
Date Tue, 04 Apr 2017 18:08:28 GMT
Hi folks.

I just read this freshly-posted article and it put the finger on a
question I've been asking a lot in my project/team using CouchDB.

In the third Q&A, Nolan says:

> CouchDB’s superpower is sync. Sometimes I even try to explain it to 
> people by saying, *“CouchDB isn’t a database; it’s a sync engine.”*
> It’s a way of efficiently transferring data from one place to another,
> while intelligently managing conflicts and revisions. It’s similar
> to Git. When I make that analogy, the light bulb often goes off.

*“CouchDB isn’t a database; it’s a sync engine.”* rings a bell
because we've been effectively sacrificing the sync-ability of
the projects data store, for reasons I'll detail now.

What we have been doing is adding a layer in front of Couch,
responsible for the following tasks, ordered by importance to us:

1. Reduce facts. In order to avoid conflicts, we are using Couch
    as a store of immutable timestamped "facts". For example,
    fact = {'date: '20170401', 'a': 1, 'b': 2} and
    fact = {'date: '20170402', 'a': null, 'b': 3, 'c': 4}
    are reduced to {'date': '20170402', 'b': 3, 'c': 4}.
    The front layer does this time-ordered reduction, which can't be
    done in Couch2, whose reduce functions have to be commutative.

2.a. Do as much server-side logic as possible, in order to minimize
      what has to be done client-side. (We have multiple clients
      and don't want to ship/repeat logic down there).

2.b. Provide a nice domain-meaningful URL scheme, and
      shield clients from Couch-level view interface changes.

3. Perform document-level access rights.

4. Do things out of reach for Couch, like pseudo-joins.

As we add more valuable features to this layer, the provided client
endpoints get ever less "Couch-like" and lose their Couch <-> Pouch
sync-ability guarantees.

We started with "magically updating" client prototypes humming
on Pouch-backed stores rendered by $whatever_rendering_js_lib and,
a few months later with the new intermediate layer, we're back in
the client to manual HTTP calls and manual binding to filtered
_changes when some magical update is desired (whereas it used to
be the default).


View raw message