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.

Playing With ExtJS

I've worked with the JavaScript framework jQuery before and I've heard of Ext JS but I wanted to try it for myself. Essentially the main difference between jQuery and Ext is that while jQuery works great tacked on top of other JavaScript frameworks like ASP.NET or JSF, Ext is more of a replacement for those frameworks. Coding in Ext feels like Swing or Windows Forms but for the browser.

Since Ext forms live completely inside the browser's memory space there isn't a postback every time you click a button or expand a tree node like there is in ASP.NET. I think the delay from a postback makes the user experience feel choppy, especially if you don't have a fast internet connection. ASP.NET makes it very easy to hook into any DOM event, but since these event handlers live on the server, hooking into these events causes a postback which in turn causes the whole page to reload. Moving all this event handling logic to the browser makes the application seem a lot faster.

Since it requires so much JavaScript coding (and so little HTML coding), you should invest in a good JavaScript editor. Ext Designer is a WYSISYG drag-n-drop editor for Ext controls. The pricing seems kind of steep to me, $219 for a single developer license, but I suppose that if you're going to use it a lot then it's probably worth the money. Take a look at the screenshot of Ext Desinger below.

There's a list of controls on the left. You drag a control onto the form, re-size it, edit its properties and preview the whole form. It's very easy for laying out the form (especially if you're not familiar with Ext). You can even setup all the data sources (AJAX calls) for controls, like the grid or the tree, and then preview the form with real data. The major shortcoming is that it's only a UI designer - there is no integrated code editor. You have to export the project to add all the program logic and event handlers via another editor like Eclipse. On the other hand, using the designer in conjunction with another editor isn't particularly difficult if you have the designer project saved in the same folder as the rest of your application, its just a little painful to have to switch between applications, I suppose.

This being my first experience with Ext I have to say that I'm relatively impressed. JavaScript has come a long way since the days of dial-up modems and table-layout. With the dawn of efficient browsers and HTML5 I think creating true fat client web applications is a reality. In a follow-up post I am going to talk about CouchDB and how using Ext with CouchDB could possibly replace the need for server-side code altogether.