Node.js (Express.js is a simple web framework for it) seems like a nice replacement for say... Python or Java for your middle layer. So:
That would mean you still need some random implementation of a b-tree in a file so your application can remember things. JavaScript on the front end, JavaScript in the middle, why not JavaScript in the backend. This seems perfectly reasonable:
Ah CouchDB, the JavaScript friendly database. TO THE GOOGLE!
I came across this quite nice presentation from Js Conf discussing node.js and couchdb. It has a title you can't refuse: node.js + couchdb = Crazy Delicious. A formula only rivaled by Red Vines and Mr. Pibb. Anyway, this video hit me with this little number:
That's right node.js as your backend and your database as your middle. *starts twitching* Now it seems couchdb is sort of designed for this scenario with a create concurrent connection story, the ability to render html templates, and some kind of built in user security/session model. Also couchdb only speaks HTTP through a REST api. Quite the nice fit for interfacing with web clients it seems, but there are some bumps in this road. Couchdb is a bit of a sandbox.
It seems this model works by node.js listening on the _changes api from couchdb so that it can perform things that require sending e-mails, integrating with external services, manipulating multiple documents; things like that. How intriquing and unconventional.
This _changes api seems to allow for polling for updates since a previous one, long polling to get an single update when it happens, or a continuous streaming of updates as they happen. You can also implement filters for these so you get what you want. Pretty sexy sounding actually.
Node.js as a backend must mean a couple of things (I think). First thing that comes to mind is you could design a system that triggers events off of it's logging. So you log that the user wants to send an e-mail, then node.js picks that up, sends it, updates the document as sent. I'm not sure if that is a good design. It's interesting to think you log what you want to do, then it happens. The client just does a poll for that update and notifies the user it's complete.
Second thing that comes to mind is that you have to design your system around being asynchronous. The client code would write/update the documents, node.js would pick it up, perform the action, update the database. To my knowledge you couldn't do that synchronously. This is probably an advantage that you are forced into this.
Anyone think of some strange scenarios to show disadvantages of this scenario? In the "enterprise" world we seem to be moving towards message passing and message queuing... basically an asynchronous world.
The simple idea of CouchDB with a Node.js backend hit me pretty good. I want to explore this idea some more and hope to write a little project. Maybe a custom single social posting app thing. Post it once in my database then node.js picks it up and posts it to my Facebook, Twitter, maybe something else. Then have node.js pick up replies/comments and post them back into the database for a single social global view.
