I'm always sad to see that CouchDB and its PouchDB counterpart in the browser (or even on the server) are always forgotten, even though they've been solving that problem for years now:<p>* easy replication (protocol is documented (<a href="http://docs.couchdb.org/en/latest/replication/protocol.html" rel="nofollow">http://docs.couchdb.org/en/latest/replication/protocol.html</a>), and it's only HTTP+JSON)<p>* The replication is reactive, ie you only get the changes since last time you synced<p>* The replication is realtime, it can use longpolling or server-sent events.<p>* 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.<p>* 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.<p>* There is filtering, although it can be inefficient and is completely controlled by the client (so no security filtering from the server)<p>* 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 (<a href="http://developer.couchbase.com/mobile/develop/guides/sync-gateway/channels/intro/index.html" rel="nofollow">http://developer.couchbase.com/mobile/develop/guides/sync-ga...</a>) but it's non standard<p>We need to iterate on the CouchDB ecosystem, because it already provides a lot of what we need.
Provocative article indeed. But some of the visions seem but naive to me:<p>Running exactly the same validation twice wouldn’t make data more valid.<p>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.<p>Network failures... should not undermine our consistency guarantees.<p>Offline... I should be able to do local modifications, then merge changes when I get back online.<p>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.
Now consider following:
- There are mobile apps, which do not talk directly to database.
- There are online games, that do not talk directly to database.
- There are Cloud based apps on your computer, that do not talk directly to database.<p>So why Web apps should talk directly to database?
"No, eventually DB will talk directly to the browser."<p>Essentially, this is what REST is -- a ("NoSQL") database over the HTTP protocol.