Node.js + CouchDB vs CouchDB

Question

I\'m questioning myself why should I use combination of Node.js + CouchDB versus CouchDB standalone approach. What are the benefits of getting Node.js into the game? Any comment

Answer 1

One of the benefits of using NodeJS in front of your CouchDB database is that you get more flexibility when implementing constraints.

CouchDB only allows you to write validation functions in design documents that check the document that is being created/updated/deleted. It is not possible to access a other document that is stored in the database from within a design document.

You might want this functionality if you need to check for the existence of document X before inserting Y.

Answer 2

What Node can do and CouchDB cannot

Node.js can do inter-process communication using unix sockets, real time file uploads, it can start a websocket server or even a SPDY server.
You can create a DNS server or even handle some geo targeting stuff (MaxMind db).

Nice stuff CouchDB can do

However there are a lot of interesting things you can do with CouchDB, even if they would be a little more difficult to achieve. For example using the _changes feature you could do inter-process communication, a real-time chat system (long-polling).

I'm no expert (but CouchDB is top priority on my to-learn list), but I guess you could also simulate sessions for logged in users.

CouchDB is amazing and so is Node.js, so the important thing is what application are you planning to develop, what's your use case.

Answer 3

Nick's answer is a particularly intriguing one. To underline the approach, here's a video by Mikeal Rogers when he worked at CouchOne (?) suggesting the couchdb + node-behind approach: http://nosql.mypopescu.com/post/2896329122/node-js-couchdb-crazy-delicious.

On the other hand, I think there's one area that even that innovative approach falls down and that's (more sophisticated) security. Basic levels of security work fine, but if you want content controlled by more sophisticated levels of security, couchdb's map-reduce doesn't cut. However, some simple node.js could.

So for some security reasons (i.e., to avoid unsecured map-reduce results), node.js could be better on the front-end to implement those security measures.

FYI.

Answer 4

There is a third option: CouchDB in front, with Node.js in back...

Traditionally, a database is on the back-end, not the front-end, so this configuration seems sort-of "backwards", but hear me out...

In this configuration, you still serve all of your pages from CouchDB ( instead of Node ), and you use Node as a sort-of "worker process" that polls the DB for "jobs", processes them, and inserts the "results" back into the DB. This way you can use the full power of Node to do special processing, but you keep all the benefits of serving your app from the CouchDB.

Actually, in this configuration, you could have any kind of specialized workers that run Python or Java or Ruby or whatever. For example, suppose you have a "Create-PDF" function on your website, and you want to use Python to actually create the PDFs. You simply write a python program that watches the CouchDB for any "PDF_Request" documents, processes them, and inserts the PDF files back into CouchDB. You do not have write your whole app in Python, you can just write your PDF Create function in Python, and leave the rest of your app unchanged.

Now, suppose you replicate your CouchApp to another computer or a mobile device ( which runs CouchDB but not Node or Python ) No problem, you can still insert a "PDF_Request" into your CouchDB. When you eventually sync-up with the server, your PDF Request will then be seen and processed by the pdf creator program, and you will get your PDF File. Your couchapp still runs on the replicated CouchDB even though the "helper programs" are not there, because they are completely de-coupled from the main app.

I am not saying that this is "the way to go", just that because of the nature of CouchDB, this configuration is actually a viable option, and will give you benefits of scaling and replication that you would not get if you put Node in front and CouchDB in back.

Answer 5

couch on its own (couchapp):

apparently, couchdb can do a lot of cool offline stuff - e.g. user goes offline, carries on, and syncs on reconnect. i haven't had a reason to use this feature yet, but it makes a lot of sense for mobile phone webapps and I'm looking forward to having a go:

http://googlecode.blogspot.co.uk/2009/09/chris-anderson-couchdb-relaxing-offline.html

node.js is designed to run server-side, so its not a great fit for this use case, except in the architecture described in nick perkins's answer.

node + couch

if you're doing anything more than a simple js app, node has a vibrant community with all kinds of libraries and packages to do pretty much anything.

this approach also allows you to hide couch behind a firewall, and only let people speak to it through your node app.