Couches in Browsers

A little while ago, Vladimir Vukićević wrote an excellent blog post outlining the reasons why he’s not a fan of exposing a specific implementation of SQL to Web Content.

I agree with everything he says in his post; I’ve also been a fan of CouchDB for some time. A CouchDB-like API seems like a nice solution to persistent storage on the Web because so many of its semantics are delegated out to the JavaScript language, which makes it potentially easy to standardize, as well as easy to learn for Web developers. Furthermore, CouchDB’s MapReduce paradigm also naturally takes advantage of multiple processor cores—something that is increasingly common in today’s computing devices.

To explore the possibility, I decided to spend some time prototyping a JavaScript implementation of CouchDB, which I’ve dubbed BrowserCouch. It’s intended to work across all browsers, gracefully upgrading its functionality when support for features like Web Workers and DOM Storage are detected.

Right now this is very much a work-in-progress and there isn’t anything particularly shiny to see; just the test suite and the semi-large data set test. In the future, it’d be great to make CouchDB’s Futon client work entirely using BrowserCouch as its backend instead of a CouchDB server, but that’s a ways away.

If you’d like to see some code samples of what the BrowserCouch API currently looks like, check out the annotated source code for the test suite. You can also read the primary source code documentation for more on BrowserCouch’s implementation. And if you’re interested in hacking on the code, the Mercurial repository is right here.

24 Replies to “Couches in Browsers”

  1. Cool. I agree that the Map/Reduce paradigm is certainly intuitive for javascript development. It breaks my heart to have to deal with SQL for ajax development!

    However, there are performance issues of this kind of approach. The good thing about SQL databases is that indexes can be used to give O(log n) access to certain queries. (Ok we are probably talking about tiny databases on the client).

    Whilst I can imagine ways of allowing map/reduce style functions to use indexes as well, this gets complex very quickly. Whats your plan?

  2. I think the MapReduce angle here is really very very promising. Not only does it scale well across multiple local cores, but extending it to operate on remote resources can be pretty seamless as well.

    Thanks for doing this, I think it’s a great contribution to the search for sophisticated, web-appropriate storage capabilities.

  3. Please do send your findings to the working group. It would be great to discuss something concrete; right now, the only concrete proposal is the SQL stuff, which is why we’re using it at the moment. If people can be convinced by your proposal, maybe we’ll use that instead!

  4. @Atul

    Great stuff! As per @kowsik’s comment, if we can merge efforts to get a pure-JS CouchDB implementation (or a close enough approximation to run Futon and other tutorials (like the interactive jscouch on Github), that’d be great.

    @Alastair: CouchDB stores intermediate and final MapReduce results in a b+-tree with amortized O(log n) access. Not that Atul is proposing embedding CouchDB, but the concept can be borrowed.

    But then, why not do the embedding? 🙂

  5. Hey Atul, I always knew you were headed for greatness.
    I am a teacher now. Who would have thought. I guess after driving all of my teachers nuts I developed a soft spot for teaching

    Josh Mendelson

  6. That’s interesting in how this concerns web storage. Could the principles of CouchDB apply in another area, browser cache? Mozilla ought to improve the browser cache system. CouchDB struck me as an interesting idea. In the end, I don’t think it would work quite right to simply run CouchDB in Erlang inside Firefox. OTOH, I still think investigating a new, document-oriented database approach might produce an innovation and improvement to the cache system. Re-writing CouchDB in Javascript might be feasible. I know this is a bit off-track from what you are discussing here, but I thought I’d mention it. Good luck.

  7. This is really great!

    I think this would go very well with PersistJS.
    It’s a JavaScript library that basically wraps all the client-side storage APIs into one object. It works with localStorage/globalStorage, HTML5 SQL storage (Safari), Google Gears, even IE’s userData behavior, and a Flash-based backend, and cookies as a fallback. So it covers just about every browser.

    Interestingly, PersistJS’s storage object almost already implements BrowserCouch’s Storage interface as it is, except that its methods are called get and set instead of get and put.

  8. What is the license for all this? Didn’t see it anywhere.

    I’d like to use this to run a few MapReduce jobs on my blog. But I’d also like to post the result of my toils so that others can do the same. Is this okay?

  9. Atul,

    This is good work. I was very excited to find it because I need just the thing, and was even prepared to build it myself. But I browsed the code and it seems that replication is not there yet. My main goal is to replicate between BrowserCouch and a real couch instance. I would like to contribute to this project to make that happen. However I couldn’t figure out how to fork your HG project. Could you let me know what’s the best way I can work with you on the code, and what’s the overall status of the project?

Comments are closed.