1. What are you using Node.js for? Is this for a new or existing project?
2. Why choose Node.js for the project?
3. What performance gains/benefits did you see, if any?
4. Any lessons learned or gotchas?
http://www.w3counter.com/stats/pulse/1
2. I got tired of fussing with kernel network config tuning, and I'm more confident with writing servers in node than C/C++.
3. A reduction in TCP sockets needed to handle a few thousand concurrent connections from several tens of thousand to just the few thousand. The request/response model of doing it in something like PHP meant there were connection from the users to nginx, nginx to php-fpm, php-fpm to the database for each user -- and it increased at more than just 3x the number of users since TCP connection stick around a while after they're finished waiting for any out-of-order packets and such.
A reduction in time-per-request from ~70ms to ~1ms. No initialization/db-connect/teardown per-request means node can do its thing and dispose of the request much faster than PHP, which was the original language this was written in some years ago.
2. The correct, proper answer is very, very long. Too long for a HN comment. The short version is that the product is I/O heavy since it mostly just queries a database and returns the results to the user over HTTPS. Node is primarily designed for this use case.
3. Per-query memory overhead is less than a threaded approach. Javascript is one of the fastest scripting languages when it comes to string manipulation which is what the API server does besides I/O. Node itself is written in C/C++ so it is quite fast too.
4a. Being single-threaded, it is very sensitive to CPU-bound tasks. I am actually working on refactoring some code to support streaming because there is an edge case that is CPU-bound and stalls the whole process.
4b. A big downside for my use case is handling 64-bit integers and numerics since Javascript does not natively support these data types, but are very important to support in a database product. We have worked around it using strings. The API server does little computation itself, so it isn't that big a deal.
4c. If you are doing a lot of CPU-bound work or computation with large numbers, then I strongly recommend not using Node. Otherwise it is probably okay even if your use case is not what Node is primarily designed for.
I should also point out that I have been developing software for a long time and have learned to become skeptical of the latest language, framework, tool, etc. I have seen so many of them come and go. It took some convincing for me to decide on Node for Datalanche. I am a big believer is picking the right tool for the job rather than the latest trend. I will be the first to say one should pick Node because it is the best for the use case.
That's interesting about using strings to work with 64-bit integers.
Well said on picking the right tool for the job.
We use Node.js for everything we do, from mobile app backends to websites to web apps. We've been using it for nearly two years, and found it fantastic - compared to technologies we've used previously it's faster to develop in, faster to run, easy to deploy (especially with platforms like Heroku) and the value of npm and the ecosystem of high quality open source packages is hard to overstate.
We have also developed an open source Node.js model-driven CMS / web app framework called KeystoneJS (http://keystonejs.com) which is built on Express and MongoDB and has been getting some great feedback :)
The biggest lesson / gotcha has been getting into the different mindset - especially when we started, there wasn't a lot of 'hand holding' available compared to other languages and frameworks, and there were few established best practices to follow. I think it's easier these days (there's certainly more out there) but I'm very familiar with it now so it's hard to gauge from a beginners point of view.
It's easy to fall into traps with callback patterns and error handling, for example - so you really need to get your head around what's out there (like the async library for example), and how to structure your application and code.
Before using Node.js had y'all done a lot of work with async code-bases?
For example I have a HTTP-server in node that accepts POST requests and sends their bodies over to an XMPP server.
For a bigger project http://blogspam.net/ aims to classify blog-comments as spam/ham in real-time, and the entire server is written with node.js. (It really just receives JSON objects, scans them with a series of plugins, and sends back a reply saying "OK" or not. Conceptually simple.)
Finally my email stack is powered by node.js, handling 30ish virtual domains with recipient testing, and anti-spam at SMTP-time. This is built around Haraka, which is a reimplementation of the ideas found in qpsmtpd. (A server I once built a small company around.)
Generally I've chosen node because it was fast to get "a scalable server" up and running with. Both the blogspam service and the mail handler were initially perl, and both received 20-40% speedups for free (well if you don't factor in my developer time).
Node.js has proven to give us good performance benefits and ease of development, maintenance and scalable deployment compared to PHP and .net, the other two platforms we usually work with.
I am not aware of the old metrics, but as per my seniors, we have got a very good performance improvement on the API services by using node. The rest of the node projects were new projects.
We use Node.js for our entire client-facing stack including an API server for code generation, a command line client for pulling updated code from the server, plus we use it for our public website.
We're currently evaluating using Node WebKit (https://github.com/rogerwang/node-webkit) for building a cross-platform desktop UI for our CLI tools.