Clarifications to My CouchDB Post

I got great feedback on my previous post about CouchDB, and I wanted to clarify a few points.

mattly pointed out that there is still need for a middleware tier, since client-side Javascript is not a reliable way to do validation or security, since Javascript can simply be turned off.  Andrea Schiavini wrote that Rails is much more than a database tier, and that Rails has plenty to offer beyond ActiveRecord (Rails’ database connector). Both objected to my referring to middleware tiers like Rails as “obsolete”.

Regarding mattly’s point, I really should have said “most of this is going to be obsolete”, not all.  He gives several examples where a middleware tier is necessary because CouchDB doesn’t have a system in place to deal with certain tasks (like comment spam detection).  However, my understanding is that CouchDB’s upcoming security model really is supposed to replace the middleware tier.  What prompts me to say this is the focus on “CouchApps”, which would run on the user’s computer (CouchDB and all), and synchronize the database with a master (“Eventual Consistency”) when the client was finished.  In essence, it’s a way to cache the database on each client.  Security/validation then becomes a matter of which client databases are allowed to update the master.  As far as I understand, it’s very similar to the git source control security model.  More here.

For a more traditional web-based application, I would put CouchDB behind a firewall, open up GET’s via a proxy (like Apache) but restrict other methods to go through a very simple middleware tier (this helps with Javascript domain restrictions as well).  The middleware tier is not completely gone, as mattly correctly noted, but it’s down to a handful of scripts, not a full-blown application stack.  This assumes that CouchDB’s upcoming security system doesn’t already provide this functionality.

As far as Rails goes, I happen to be a full-time Rails developer, so I’m quite familiar with the benefits of Rails!  However, much of what Rails offers beyond ActiveRecord is also deprecated in CouchDB’s model.  For example, routing becomes less important when you’re building an AJAX-driven application with CouchDB.  Simply grab the view or document you need with AJAX, and render your web page client-side based on the result.  CouchDB takes care of the routes to the various views and documents already, so you’re left with a few static HTML documents and Javascript libraries that don’t particularly need routing.  Environments in Rails are also less useful when working with CouchDB.  In CouchDB, each database is its own environment.  As long as the databases have the same name on each server, no code has to change.

Anyway, thanks for the feedback, and I look forward to talking more about CouchDB in the future!

:-Daniel Tsadok