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

Advertisements

12 Comments on “Clarifications to My CouchDB Post”

  1. Another great project with some of the same goals is Persevere (http://www.persvr.org/). It is a bit further along than CouchDB in some of the middleware features such as authentication and access control, though it lacks some of the distributed and replication features of CouchDB.

  2. danieltsadok says:

    Thanks Nathan!

  3. I would still use a server-side framework for a few reasons:

    Some logic just belongs on the server, rather than the client. Authentication is one obvious example, but it’s not the only one. I would say, divide up the server and client parts of your application and make intelligent decisions about what state is kept by each, what logic resides in each, and design a good API for the server to provide to the client. A good design will support any future clients you might want to add (an iphone app, for instance).

    CouchDB has a particular form for its routes. It’s basically /[database_name]/[big_ugly_sha_hash] to fetch a document and /[database_name]/[_view_name]?[query_params] to fetch all or part of a view. This is a fine interface for the application to use to talk to its database, but I don’t necessarily want to expose it to an end user. Suppose I want to give each user his/her own subdomain, or the first part of the path in urls relating to them. I should be able to decouple this decision from my infrastructure. The routes used by an application are an important part of its public-facing user interface.

    I suppose the CouchDB team could add the ability to write an arbitrarily complex server-side application that runs entirely within a CouchDB instance (is this what CouchApp is?) but I’m not sure I understand the reasoning if they do. I would rather have more replication/distribution features for the database itself. Application logic can already be written using dozens upon dozens of great tools with large communities in a variety of programming languages. The database tier itself is where we could really use the improvement!

  4. John Wheeler says:

    I downloaded CouchDb and played around with it after watching the peepcode screencast. I also played around with Futon, and while doing so, I looked at futon.js and the jquery CouchDb plugin, which, I am assuming exports a full CouchDb persistence API in javascript. So, I can see how this thing supports full blown app development. That it almost forces you to use REST to create business abstractions could be all for the better.

    But, in order for this thing to make current server frameworks obsolete, you’re going to have to have the same third-party API support those other languages do. What do you do about image processing, security algorithms, Word to PDF conversion? You’re not going to find JavaScript libraries for those, so you can say this is for a class of apps, but wouldn’t those apps be the most basic ones?

  5. danieltsadok says:

    @Charlie and John – I’m trying to put some of these ideas to the test myself. I may end up running back to Rails, or I may find that I can write a relatively complex app with only AJAX and CouchDB. Probably it will be somewhere in the middle! I’m guessing that a simple CGI script will suffice in most cases where server logic is actually necessary. I’m also examining generating HTML in CouchDB itself, which seems to be on the agenda.

    @Charlie – just a nit-picky detail: the ugly URL’s are not necessarily ugly if you select the document id yourself. Also, these URL’s are not exposed the user if you use AJAX to talk to couch. And there’s always mod_rewrite to pretty things up :-)

  6. I’ve been influenced a lot by Sam Ruby’s book on RESTful web services, so that’s the background on where I’m coming from.

    The idea is that the url should name the “resource” that the requester wants to work with, and the HTTP verb should give the action (GET, POST, PUT, DELETE etc). The requester should be able to specify what sort of representation they want, either in the “Content Type” header or with a dot extension on the end of the url. This is the way HTTP was meant to be used and I’d like to try and design ‘with the grain’.

    I’d like the user to be able to visit any resource by typing a friendly url directly into the browser. Even if they have javascript turned off, or are using a device that doesn’t support it, they should get an HTML page that works. If they’re requesting raw data (eg giving json or xml as the extension or content type), the resource should be returned in the requested form.

    Rails (and Merb, and others) happens to map very nicely to this simple, versatile way of handling requests, which is one of the main reasons I like it so much. I might like a standalone CouchApp too, if it will also support that way of doing things.

    Finally, I consider the URLs to be exposed to the user if they’re part of the public-facing application, whether the user sees them in the address bar or not (due to some ajax trickery). I think a fundamental part of web usability is that users should be able to go directly to a resource by following a friendly url.

    • danieltsadok says:

      My CouchDB URL’s look friendly and RESTful…
      For example:
      GET /products/ (gets info about the database “products”)
      POST /products (creates new document in “products”)
      GET /products/shampoo_bottle (retrieves the document “shampoo_bottle” from “products”)
      PUT /products/shampoo_bottle (updates “shampoo_bottle”)
      etc….

      Also, you can have ugly autogenerated ID’s for each document if you want, but that’s a choice CouchDB lets you make. Meanwhile, Youtube uses something like Base64 encoding to do their unique ID’s, and Facebook uses large integers. I wouldn’t say those are particularly better than Couch’s hex…

  7. I agree that youtube and facebook use ugly urls. I don’t think they’re a good example to follow.

    The example you gave is fine, as far as it goes. But as you say, that requires that you not use uuids as document ids. I kinda like the idea of using uuids. And, if you want more nested routes (eg /articles/my_wonderful_article/comments/3) I don’t remember seeing support for that…

  8. Scott Shumaker says:

    There’s some truth to these observations – I think you’ll begin to the role of web stacks diminish a bit with more widespread acceptance of CouchDB, especially if you’re generating your HTML dynamically on the client-side.

    For a while, you’ll still probably want the fancy routing rules that Rails provides, but eventually I could see that being moved to CouchDB as well.

    The authentication layer needs a lot of work before you could obviate the need for a web stack entirely. In the meantime, I expect most people will have a thin authentication layer sitting in-between CouchDB and the client.

    The other big component of rails is the ORM (ActiveRecord). You still might need some sort of light-weight ORM, although obviously this is way simpler when you can just store objects directly.

    But just because you don’t have much of a webstack doesn’t mean you won’t be running a lot of back-end code. There’s a huge variety of tasks that CouchDB isn’t well suited for. You won’t be able to get rid of your job farm (resizing images, converting videos), your message queue system, etc. CouchDB can’t send emails, communicate with external web services, and so on. And of course, you’ll still be running cronjobs for analytics, purging old data, archival and such.

    Really, the biggest change (from a Rails point of view) is that your controllers and models will greatly shrink in size – most of this code will live in the client.

  9. top max team says:

    CouchDB offers an API as a means to retrieve data from the database…. Views in CouchDB are created on demand and can be used to aggregate, join, and report on documents in the database… They are built dynamically and have no effect on the documents in the database….

  10. couchone says:

    To follow up on this. Many of these features have been implemented in CouchDB. Routing / rewrites, and server-side validations and template rendering are the big ones.

    Just an FYI for folks who stop by this post looking for info.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s