Writing CouchDB Views using ClojureScript

DZone 's Guide to

Writing CouchDB Views using ClojureScript

· Java Zone ·
Free Resource
While I was in San Fransisco for JavaOne, I was lucky enough to be invited to speak at the Bay Area Clojure User Group (thanks, Sean and Toni!).  It was a great time, and gave me the kick in the pants I needed to finish hacking away at my first project involving ClojureScript: using it to write view functions for CouchDB.


The result is clutch-clojurescript, which naturally builds on top of the Clutch library that I’ve collaborated on with Tunde Ashafa for some time now.

My motivations for doing this were manifold:

  1. I quite enjoy using CouchDB, as its model and general philosophy meshes very naturally with my (and my tools’) disposition and the data I work with most often.
  2. The operational hassle associated with maintaining a Clojure view server (which Clutch provides) configuration alongside my CouchDB installs was always a hassle.
  3. I’ve been wanting to do more and more with Cloudant, but a Clojure view server is just not an option with a hosted database-as-a-service like that.
  4. I can’t stand writing JavaScript.  Give me the reach of JavaScript, but with sane abstractions, homoiconicity (macros!), and data structures that aren’t braindead? Sign me up.

Feel free to go check out clutch-clojurescript: beat on it some, and let me know if it breaks on you.  I would eventually like to fold it into Clutch proper.  Beware some limitations though — repeated here from the README in part to draw attention to them:

  • ClojureScript is not yet available as a proper library. This forces me to include some binary version of it in this git repo (a hefty 8.3MB!…which includes various google JavaScript UI bits that I’d hope would be broken out eventually), and bundle the necessary bits into the clutch-clojurescript jar. I would very much like to roll clutch-clojurescript’s functionality into Clutch proper, but I’ll not do so until the latter can rely upon a ClojureScript dependency.
  • ClojureScript / Google Closure produces a very large code footprint, even for the simplest of view functions. This is apparently an item of active development in ClojureScript.

    In any case, the code size of a view function string should have little to no impact on runtime performance of that view. The only penalty to be paid should be in view server initialization, which should be relatively infrequent. Further, the vast majority of view runtime is dominated by IO and actual document processing, not the loading of a handful of JavaScript functions.

  • To my surprise (and shock/horror), the version of Spidermonkey that is used by CouchDB (and Couchbase Single, and Cloudant) does not treat regular expression literals properly — they work fine as arguments, e.g. string.match(/foo/), but e.g. /foo/.exec("string") fails.  Using the RegExp() function with a string argument *does* work.  This was reported a long time ago, but has had little attention (though I’m trying to stir it up a bit).

    I’m hoping to get to the bottom of this sooner or later, but I wonder if it’d be worthwhile to change the ClojureScript reader to emit (js/RegExp "foo") calls instead of /foo/ literals (and hope that gClosure doesn’t optimize the former into the latter)?  After all, there’s lots of CouchDB deployments out there with apparently broken spidermonkey installs/configurations, and likely lots of other apps/servers/environments in similarly dire straits.

Finally, here are the slides from my talk at the BACUG (download/view PDF):


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}