CouchDB + Ext as a Replacement for Server Code

In a previous post about ExtJS I mentioned the possibility of developing a web application that runs entirely inside the browser and doesn't require any server side code. The idea stems from a) ExtJS is a fully capable widget framework and b) CouchDB is accessible via a web service. At least 80% of web apps are just a HTML interface with a database back-end and a little bit of business logic. So why can't we move all that business logic to the browser, setup calls to a CouchDB web service from the browser and 86 the server-side code? In this post I'm going to analyze this question and see if it's realistic. In a follow up post I'm going to analyze this same question from a business standpoint.

A Database Void of Schema

CouchDB is a document oriented database, meaning that it doesn't have tables and keys like you do in relational databases. It just has one big space full of documents. A document in CouchDB is a JSON object, so its attribute values can be strings, booleans, numbers, lists, or other objects (documents). Having complex "rows" means that many of your relationships that you would normally form by using a second table and a primary-foreign key set is simplified down to embedding a list. Consequently, 1-to-1 and 1-to-many relationships are native to the database and require no extra thought or planning. Many-to-many relationships are more complicated, so this approach might break down if you require too many of these. Some other oddities in relational databases like versioning and pivot tables come native with CouchDB. Since the bulk of our database requirements are made easier with CouchDB, querying is going to be generally simpler.

The other great thing about having a document formatted in JSON is that you can save any JavaScript object directly to the database. You could save the state of an Ext widget or a whole form. It's like simplified object serialization for the browser! This is definitely a killer argument for making fat client apps with Ext.

But What About Performance?

At some point, someone's going to ask it. I say, Twitter uses it, they seem to be doing well, there's one case that its proven itself. The biggest argument for CouchDB being a scalable database is the fact that it is built from the ground up with the intent of being distributed across many nodes in a cloud. So while it is easy to get a database stood up for development, it's just as easy to move that database into a highly distributed cloud with hundreds of nodes. This makes it easy to develop scalable world-class apps like Twitter or Google.

CouchDB uses a type of index that is based on the map-reduce algorithm used in functional programming. You define a function in JavaScript that takes a list of values and chooses which ones to include in a view. When you want to query the database you just ask it for all or part of a view. Because it uses the map-reduce algorithm to index, it's agnostic towards when and how many documents are indexed at a time. So documents can be quickly indexed on insertion/creation, or the whole database can be indexed at one time.

If the client code is developed entirely in Ext and JavaScript, all forms are static HTML pages, so the server can easily respond to 80% of requests with little more than a few HTTP headers (client-side caching).

What About Security?

At this point someone must be ready to blurt out something about this being an incredibly insecure approach to web development. After all, any slick hacker can modify the JavaScript code and execute arbitrary insertions/deletions. Security is definitely going to be a lot bigger of a concern in this case. However, CouchDB does provide fine grained security controls. Here is an informative video about CouchDB security controls.

The big difference with designing security into couch apps is that security is going to be built into the database instead of the application. CouchDB provides constructs for users to be part of roles. If constructed well, the developer can leverage the database to deny or allow certain operations for the current user.

Taking the Ext + CouchDB approach is going to be a fundamental shift in application design. If we learned to write apps like this we might actually learn to rely on the framework to do what it does best, and let our app do only what it needs to do. We might even find ourselves making stable and secure apps in less time.

Conclusion

From a technical perspective, I think this might be a very feasible design paradigm. In a coming post I am going to talk about the business costs involved. However, I think document oriented databases might be something I want to investigate further and design into future applications.