Sync Gateway best practices (shadowing vs API)

I am working on a project that uses Couchbase Server and Sync Gateway to synchronize the contents of a bucket with iOS and Android clients running Couchbase Lite. I also need read and write access to the Couchbase Server from a Node.js server application. From the research I’ve done, using shadowing is frowned upon (, which led me to look into the Sync Gateway API as a means to update the bucket from the Node.js application. Updating existing documents through the Sync Gateway API appears to require the most recent revision ID of the document to be passed in, requiring a separate read before the modification (, which seems potentially inefficient. What is the best way to solve this problem?


I’m having exactly the same question and looking forward to an answer on this question.

Anyone have an answer to this? I feel like this is very important to know when deciding whether or not to use Couchbase at all?

If you want to avoid conflicts, retaining the most recent revision id for your document is the way to go. Typically this doesn’t mean an ‘extra’ read-then-write - you retain the revision id on the original load of the document, and only need to do a read-then-write when someone has updated the document underneath you.

@adamf Thanks for the response. How do you tell if someone has updated the document underneath you though from a server application? Wouldn’t that require a read?

You’d get a 409 error back on your attempted PUT if the document has been updated. At that point you’d need to do the read before you can attempt to write again. Often that’s the desired functionality from the application’s perspective - you want the user to be aware of the changes that had been made to the doc before they overwrite those changes - but if that’s not required you could hide the conflict/read/rewrite from the end user.

We’ve been following this thread and put together a guide that might help in implementing an app server to handle importing and exporting of documents.

It can be found on this pull request.

Before we publish this on the documentation site, if anyone has time to read through it and provide your feedback it would be very helpful.