Straw Man Architecture: Replacing Parse with Sync Gateway etc

Gentlefolk,

A client of mine is being forced to consider alternatives to Parse. One thought is to explore a totally different mobile architecture. Couchbase Lite and the Sync Gateway comprise one such solution. The full channel replication is quite attractive.

This particular app has a non-negotiable requirement to cryptographically sign fields in the document on the server. This is a legal requirement that data as it arrives on the server is validated and made cryptographically immutable. This signing must be done on a machine outside of the user’s control. I believe that the Sync Gateway can perform the validation and that a webhook can perform the cryptographic signatures forcing the one time mutation of the document. If the webhook is not running on Node.js and, hence, does not have access to the Node.js cryptography stack, then the webhook environment must support a pure Javascript crypto module packaged in the common fashion.

Basic architecture per availability zone:

  1. 1 Sync Gateway and Node.js application server.
  2. 3 Couchbase instance cluster or 3 CouchDB instance cluster.
  3. Cross domain replication.

While I prefer Couchbase, my client notes that they cannot identify any Couchbase as a Service providers. There is one major CouchDB as a Service provider and there may be more. At our current load, the database cluster we need is composed of small machines. It will probably help our application performance if the database cluster, gateway/app server and an S3-like file store have relatively low latency between them.

Any thoughts on whether the above architecture is an unreasonable use of Sync Gateway and Couchbase/CouchDB?

Anon,
Andrew

That sounds perfectly feasible. There aren’t any turnkey Couchbase service providers, but we do have prebuilt AWS and Docker images including Couchbase Server and Sync Gateway that are pretty easy to install. (I’m personally not an expert on that so I’ll let someone else give details.)

As for signing, yes, you’d want a server-side process that monitors the database for new documents, signs them, and writes back the updated documents. You can write this in any language you want. We call this the Changes Worker Pattern and have documentation that describes the design.

Why would you use the Changes Worker Pattern instead of the webhooks?

Webhooks can’t modify the document. They’re called when SG is storing a revision created by a client; that’s different than creating a new revision.