I love CouchDB and node.js. I have found myself using them lately, to get a lot of things done, and would like to talk about why a person might want to use them or why they might be stupid tools for building your next app.
What's It All For?
Node.js is a very fast, asynchronous server-side, V8-based, javascript implementation.
CouchDB is a REST/JSON based document-store. It can serve files, and render data based on javascript mapping functions that are stored in the database. It's a super-light webserver, with data-indexing & querying functionality built-in.
The Solution Looking For Need
Node.js is really fast, and comfy for people who are already comfy with Javascript, especially when working with other server-side Javascript implementations (like CouchDB) which use concepts like CommonJS, etc. Tasks that are made slower by blocking, synchronous operations (reading files, making network requests, etc) can be sped up quite a bit, just because of how node.js works.
Node.js solves a lot of problems that I don't have. In general, I don't get blocked by IO operations, as most of the things I make don't need to scale ginormously. PHP can do a lot, pretty fast. PHP is an old, reliable workhorse for "getting things done" and is my fallback, for anything on the web, while I generally use Python for shell scripts. I know their quirks, and I can make nice things pretty fast with them. They've both got loads of libraries that make tedious things like building MIME emails, rendering PDFs, manipulating images, etc go really fast.
CouchDB also solves a lot of problems that I don't have. I am not trying to scale infinitely, a massive app that has billions of hits. I'm not finding PostgreSQL/MySQL to be a bottleneck, I am not in need of a lighter web-server+database full-stack. PostgreSQL, MySQL, Lighttpd, nginx, and even Apache serve me well, and I have never run into a situation that code-optimization + tools like memcached, Varnish, or nginx as a proxy/accelerator couldn't solve. CouchDB can render a lot of these tools unnecessary, as it is built with these things in mind, or obviates the need, from the start. It replicates very easily, and scales massively.
But wait, why learn a bunch of new things?
You may wonder, if I can solve all my problems with PHP/Python + a decent database + an ok webserver, and if needed, some caching: why oh why would I attempt to learn a whole new stack of unfamiliar technologies that I don't really need? I'll try to explain.
I have always liked Javascript. I like the syntax, and kind of "think in it", as it was the first language I really creatively used. For years, it was viewed, by people smarter than me, as a useless toy language. This prompted me to learn "non-toy languages", like C, C++, and Java. They annoyed me with all their useless type-checking, boring compiling, and stupid, non-uniform syntax. After that, I learned more fun languages like PHP & Python. They were so great for so many things, but I missed the joy of writing smart and efficient Javascript. As things like jQuery got more popular, and larger frameworks like JavascriptMVC, Sproutcore, and Backbone.js, I started to see a trend of more useful things being accomplished on the client-side with my favorite toy language. Rhino got more popular, and became a beanshell language, which means that you can use it in all sorts of server-side java stuff, including Ant! It's so cute how you can do weird magic with prototypes that make even python's herty-gerty loose-type proponents quiver nervously in a ever-shifting vaguely Object-oriented nightmare.
So, here we are: it's the most fun for me, even if it wasn't the fastest & easiest way to blast out super-awesome web-apps, and even if I didn't love all the free optimization, built-in. If you are not new to programming, or Javascript is not the most fun language for you, or at least top-ten, you probably should quit reading, now, there are way better options for your type.
Enough about your feelings, what can I make?
So, after you have decided to delve into the awesomeness that is useful, server-side javascript, you need to write something.
You have these options (and I'm sure others that I haven't thought of) for how to set things up:
- node.js + couchdb on a webserver (web page)
- couchapp on remote server (web page)
- couchapp on desktop/mobile
- HTML5 client-side storage
- weirdo hybrid running awesomely client-side and server-side
I will explain each, in detail.
This is easiest (with your vast and awe-inspiring experience making webapps in RoR, PHP, etc,) if you want a web-only (possibly responsive-designed for mobile...) app. You get all the benefits mentioned above, including speed, asynch operations, fast data, data-replication + scaling, light web-service (node does it on it's own!)
Now, this is just cool. We start to get into some real magic voodoo type stuff, right here. You can host the whole app, in the database. It's versioned, and you can replicate the app files as well as the database. This is crazy! Slightly trickier to setup than #1, but Reapuhlster & couchbase can help make it a snap. Go make a crazy self-replicating AWS cluster couchapp version of facebook or twitter, and you will be rich! couchapps need creative solutions to secret data, that you don't want clients getting into using authentication and segmenting data on different databases (some replicated, some not.)
There are easy to use mobile and desktop versions of CouchDB. You can do the same as #2, but local. replicate to a master "app server", and you can roll-out updates, just by deploying your app. Neato! It should be noted that the mobile CouchDB stuff is super-new, and still has a few kinks to work out.
This is a great option of 1-page apps (or web-worker enabled apps.) You just use local storage. Works great for anything that doesn't need to call home or interact with other people on the internet (todo list, note-saver, etc.)
You can use the magic of HTML5 data-storage (if you know the client has it) and BrowserCouch or PouchDB, to do couchdb, too. This combines option 1 & 4, when you can't get your couchdb working correctly on the target, but you might want to do couch later, when it gets more stable on your platform. You can sync to a central CouchDB, so you get all the magic of data-replication (with a little javascript elbow grease) but no client-end CouchDB server requirements. This is also a great way to dev your app, and get all your map/reduce functions and UI stuff worked out, before deploying to a real CouchDB server (option 2 or 3.)
In later articles, I will give examples of each of these moments of development-cycle-encapsulated joy.