cdoral in another post mentions node.js. I have been following this project for a while so I thought I’d write a little blurb about it and include a few links for further and more in-depth information. Coincidentally, the Node Summit was held this week in SF, so there may be interesting and fresh material coming from there soon.
First things first: I have played with node.js for little experiments but haven’t yet found an opportunity to put it to real, production use. Version 0.6 addressed some of my questions about its capabilities and performance, and it is already being used on production servers for many traffic-heavy sites like eBay or LinkedIn, so it’s clearly gone beyond the experimental stage. If you are building a web service today, node.js is a technology you should consider.
- It’s based on Google’s V8 engine, which is being actively developed and keeps getting better, faster and more robust with each release.
- Its asynchronous, event-based nature makes it easy for node applications to support hundreds or thousands of simultaneous connections with great performance and low resource consumption, compared to thread- or process-based solutions. Many modern servers, both standalone servers (nginx) as well as server application frameworks (Hellepoll, Tornado), have gone this route.
- Node libraries and extensions use a standard distribution method called the node package manager. It’s incredibly easy to use and makes managing your external dependencies a breeze.
- All I/O in node programs (files, databases, other servers, etc) is asynchronous and usually offered in continuation-passing style. If you are not careful with the way you write your code, you may end up in callback hell. Some libraries like async will help a lot there, but do not underestimate the cost of getting used to code with this paradigm.
- node is event-based, and that’s it. It’s easy to get great performance, but sometimes you need huge performance or scaling even if it’s not easy (note – it never is!). If your concurrency or scaling needs change in the future and other approaches (multithreaded, distributed) would serve you better, you will have to engineer around node (balancers, proxies, routers, hybrid services), or entirely rewrite your code using another technology that allows other solutions (C++, Erlang).
- Many classic hosting providers do not support node.js out of the box, and require renting a virtual server. Recent contenders in the platform-as-a-service space like heroku do offer node.js support out of the box.
Node.js really is an application platform, not a plain web server – you can use one of the popular node frameworks like express to build a fully featured web server, and it will have almost the same throughput as dedicated servers like nginx or lighttpd. In broad terms, I look at them like this:
- Node.js if you’re developing a web application (and its pros/cons are ok for you). Node may also serve the client web site, but its strength is in handling the server-side logic.
- Nginx if you are serving a single, custom web site that includes an application backend. Nginx configuration is simple but powerful for both static files and cgi modules, and it can also fill other roles (reverse proxy/load balancer or mail proxy) in your infrastructure.
- Apache if you are serving multiple sites, each may be built using different technologies (PHP, uwsgi, etc), and/or each may be managed by different people or clients. Everyone and everything knows, understands and/or is compatible with Apache configuration files.
I hope to be able to talk more about node.js in the future.