Earlier quoted context omitted.
Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…
Wow, thank you. So from my little perspective, couchdb does replication over network, you are leveraging that to create apps that can queue network events locally and get on with other work, and that one definition of a record can easily be used in JS, local store and remote. Seems nice. I remember another thread recently with a discussion on replacing the standby icon. At some point someone drew up a series of dynam…
I spent a while typing of descriptions of how it works, but honestly I think you're best served by these two answers:
http://stackoverflow.com/a/4766398/17086
https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio...
It's not magic, no. It does, however, work a lot like git (a good thing!). The biggest downside is that it pushes some of the work to the client; you really do have to figure out how to handle conflicts in some cases. For example, if you edit the same field on the same doc in different ways on two different clients and then try to sync, there is no automatic way to resolve that other than throwing one edit away (which you can totally do if that works for your problem space). Luckily, that's not a very common situation. :) And, again, how else are you going to solve something like that? It all comes back to the CAP theorem - you can have at most two of consistency, availability, and partition tolerance. Rich mobile apps can work around a lack of consistency if they must, but a lack of availability and partition tolerance undermines the "mobile" part; for some projects (like mine) that is unacceptable.
As for TouchDB, if memory serves it actually was running an erlang VM at one point, but has long since been rewritten into native Objective C (for the iOS version) and Java (for the Android version). The PouchDB version is written purely in Javascript. Again, all that matters in the end is that it speaks the protocol. As @caolan put it, CouchDB is not a database:
http://caolanmcmahon.com/posts/couchdb_is_not_a_database/
It's a protocol. :)