Where Node.js Makes Sense
A JavaScript application development framework called Node.js has been receiving a lot of press these past two years, and we at COPIOUS have been hard at work building things with it to see where its strengths and weaknesses are.
We’re always eager to try out new technologies, though don’t push trends for trends’ sake. So, when node started becoming very popular this past year and a half, we were eager to get our hands in it and have a look for ourselves. When using it for a project in partnership with Engine Yard these past few months, though, we’ve had a good chance to see where it really shines!
First of all, the choice to go with node needs to be based in architectural conventions. Node is ideally suited for applications where interactions happen in real-time, and where data needs to be processed in similar ways on the front and back sides of the stack. It’s not an ideal architecture for things that rely on synchronous data processing, rather handling very well events that happen independent of each other.
Its facilities for web application development aren’t as mature as Rails or Drupal yet, but for small, highly scalable interactive applications, it works very well. Node also supports solid package management through NPM, which makes dependency management and environment setup very straightforward. It’s also very easy to get a cross-platform environment running quickly: it run as seamlessly on Windows as it does on Linux and Mac OS X.
One of the biggest strengths with Node lies in its data impedance match: the same data structures are used in the browser, in the server, and when paired properly, also in the database. It works very well with non-relational data stores like MongoDB, and allows development in JavaScript to happen without worrying about implementations across multiple versions of JavaScript.
When dealing with such a young ecosystem of module support, though, we found a number of difficulties in package updates introducing undocumented breaking changes. There were other blind spots in the framework that we expected to find but didn’t have conventions settled yet: date formatting, return values (rather than callbacks), and nesting of functions in many modules introduced architectural and technical issues that needed to be solved before we could launch the product.
In the end, node worked well for the project we built with it. We needed a real-time system with low-impedance to full stack data processing. We needed something supported and scalable with a solid community driving it, and all of these things were present in node. For interactive, real-time apps, we’re hard-pressed to find a better-fit framework using widely supported tools.