Ionrock Dot Org

My Weblog

Making a Todo List Application with CouchDB

Wanting to get a better feel for CouchDB , I figured what better way to explore it than build a small application. Usually the example application is a blog, but being rather sick of writing blog software, I decided to make a simple todo list.

I should mention that my example was not meant to be a Tada-List or Remember the Milk or some other equally heavy time management tool. While I'm sure if I could commit to using one it would be beneficial in the long run, I'm just too simple a guy to use some web service for checking off things I get done. Instead, my todo list app was based loosely on Org-Mode and its built in TODO functionality.

If anyone wants to look at the code it is here .

I'm using CherryPy because it is pretty easy to get up and running and I've found it to be a very solid server. I'm also using jQuery on the JavaScript side of things. I've tried to get accustomed to writing JavaScript in terms of jQuery plugins . This is something of a hassle, while at the same time, I feel somewhat protected via the jQuery namespace. This could very easily be a false sense of security, but after writing a simple widget framework, my impression is that when working with JavaScript, the less time you spend on the front lines battling cross browser issues, the better. There really is a better chance of the jQuery folks solving problems than me understanding issues and fixing them myself simply because they have spent more time on the issues. Anyway.

The Good.

The Python CouchDB library is pretty slick. It uses httplib2 which is a plus in my book as it does caching right and has things like HTTP Auth built in. The abstraction between the actual JSON document and the Python object is really shallow, which is a huge plus. Most things seem to work when treated as a dict , which feels very pythonic. Also, it was trivial to get started on some simple iteractive interpreter tools to help work with a database. This sort of thing is really more of a testament to Python and CouchDB than anything else. Not having to be concerned with schemas and having simplejson makes playing with a CouchDB database really easy. Finally, the python-couchdb source was very helpful for learning the library. It looks like testing is done via doctest , so the docstrings are essential.

The Bad.

I had a few errors where it seems like persistent connection was lost between CouchDB and the httplib2 connection object. Essentially, it looked like a request failed because things timed out. I'm not sure if that is the case, but from the standpoint of a user, I would prefer to ignore that kind of error in favor of making another attempt at the request. That is if the error really was due to a timed out persistent HTTP connection.

Another area that I wish would be addressed is working with views. Specifically, it was sort of a pain to figure out how to programatically add a view (which is essentially like creating an index on some part of the document in the CouchDB world). It makes total sense why this would be left out of the library because views are simply regular documents following a special convention. But, since the rest of the library works so darn well, why not add a couple helpful bits to make life easier? In this case it would probably be better for me to shut up and send a patch, so that might be what I'll do.

Lastly, I didn't see how to deal with security. One of the benefit of httplib2 is that it has HTTP Auth built in. That means I could use something like Digest to make talking to CouchDB a little more secure. Seeing as I've barely scratched the surface with CouchDB, I might be missing some obvious best practices or patterns. The python-coucbdb lib might also have some surprises that I don't know about. In other words, I'm not consciously trying to be lazy. Security didn't hit me in the face.

Overall it was a lot of fun playing around with CouchDB. I'm sure I could have done more with JavaScript, but without security in place that seemed like a bad idea. I also didn't notice the performance being a problem. I didn't do any benchmarks or anything, but things felt snappy enough to feel confident things could work. And yes, this is a totally useless subjective opinion on performance, but I'm claiming avoiding the root of all evil.

I'm interested to see what happens with CouchDB. The whole document store side of things seems really powerful. I also like the idea of views. The big question in my mind is how do the management of the views complexity scale over time. When I end up with massive amounts of data over a cluster of CouchDB servers, am I also going to have to keep track of tons of code used for the views? Assuming views can get rather complicated, what are my strategies for reducing the complexity and how do those impact performance? SQLAlchemy , a truly great ORM, does a good job helping handle complexity without sacrificing too much speed, but does adding functions available in views cause a major slowdown? Time will tell how these sorts of questions pan out. One thing for sure is that CouchDB seems like a relatively worthwhile application to take a chance on. If I were an early adopter looking for an edge, CouchDB is a good option that might pay off.