* easy replication (protocol is documented (http://docs.couchdb.org/en/latest/replication/protocol.html), and it's only HTTP+JSON)
* The replication is reactive, ie you only get the changes since last time you synced
* The replication is realtime, it can use longpolling or server-sent events.
* The replication is two-way; the browser doesn't have a special status in the replication protocol. It is effectively the same database. The application speaks only with the local database, which is sync'ed in the background.
* CouchDB effectively acts as a log of all transformations. If you modify a document, there will be a trace that there is a "marker" that tells you that the document changed since last time you saw it.
* There is filtering, although it can be inefficient and is completely controlled by the client (so no security filtering from the server)
* CouchDB does lack granularity, it is only at the database level meaning that each user must have a different database. Couchbase is going another way with channels in the Sync gateway (http://developer.couchbase.com/mobile/develop/guides/sync-ga...) but it's non standard
We need to iterate on the CouchDB ecosystem, because it already provides a lot of what we need.
Essentially, this is what REST is -- a ("NoSQL") database over the HTTP protocol.
Running exactly the same validation twice wouldn’t make data more valid.
What in a Web app scenario guarantees, that the validations are the same, that a potential attacker haven't removed the validation from client code? By embedding the rules inside database you just made it a proxy to the raw data - making it the same old, wrong architecture.
Network failures... should not undermine our consistency guarantees.
Offline... I should be able to do local modifications, then merge changes when I get back online.
So far it is proven, that to get any consistency guarantees in such case, you are severely limited in kinds of data you can process. No library can magically solve the conflicts for you as long as the data is not CRDT. There are not many applications consisting exclusively of sets and counters.
So why Web apps should talk directly to database?
