Over the last few years, the REST approach has become the new standard to build API on top of HTTP. In the same period, server-side landscape is facing huge changes along with the Node.js breakthrough
If it's easy to build a small HTTP server with few lines of code of node, why not build a real API?
If Node.js made a breakthrough in web application area, it's mainly due to the paradigme shift that it introduced which brought considerable performance gains.
At the heart of node architecture, there is non blocking IO. This is crucial for web applications that are IO Bound. The latency introduced by reading from files, networks or databases is multiple order greater than the computations that happen on the CPU. With blocking IO, the thread or processus would be idle most of the time.
Most of the node core is made of the non blocking library to handle filesystem, http, and the other low level networking protocol such as TCP and UDP.
All these operations work with a callback, a computation that will be called once the operation is performed. The function returns immediately, so we don't have to wait for the completion of our IO operation.
Non blocking IO would be nothing without a reactive approach, event driven programming that is the essence of javascript and node.
Node implements it through an event loop than will constantly handle events with their associated continuations. It's the same schema that is on the browser, schema that is also used by the high performance server such has Nginx that can handle simultaneously numerous requests with a single thread. The node runtime keeps a stack of functions to be called when some event occurs, and the unique thread will sequentially handle these events. In concrete terms, the node engine will keep a stack of functions to be executed at some event triggering, and the only thread will handle these events one after the other.
With an event driven approach along with non blocking IO, we don't need several threads to concurrently handle requests. With a single thread, we don't have to pay the context switch and other overheads induced by managing multiple threads. Besides, the remaning thread won't be idle waiting for a blocking operation to be completed. It will continuously handle events as they appear with new requests, or read completion. However, we have to be cautious, and avoid at all costs blocking the event loop with CPU heavy computation that will waste all these benefits.
With CPU being used at best, and memory footprint being low, we can use lighter servers without having to renounce to performance for our end users. Also with the absence of shared state that frees us from synchronization we can more easily replicate the application on several nodes behind a load balancer.
Hence Node.js enables to horizontally scale easily with commodity hardware. Id est cheap and easy to obtain nowadays on the IAAS or PAAS clouds such as AWS or Heroku. The exact contrary of the traditional application servers such as WebSphere or WebLogic.
Node philosophy is one of the Unix philosophy's descendants, that we could sum up as emphasizing building short, simple, clear, modular, and extensible code. Indeed node core offers a simple API and Application which are structured around small and reusable modules that focus on a single feature.
This favors maintenance and reutilisability and this has influence on the culture of node ecosystem where numerous small and sharp libraries, packages have emerged.
A huge number of small packages can easily lead to a dependency hell without the appropriate tools. Fortunatly, Node ecosystem has npm, Node Packet Manager.
Packages are described in a package.json, a standard that describes the metadata of the project and the different dependancies. This not only favors code reusability, but code sharing. Indeed it's very easy to make your modules available for the community.
Thanks to this good package management, collections of library are available on npm, libraries that are well thought-out, collectively developed (most of the time on github), performing and tested by thousands of users. Whatever your need, you should have a look on npm registry, as we already pointed out few years ago, "There's a module for that!".
Certainly, javascript language is far from being perfect, but it's getting better with the new EcmaScript versions on the go, and good linter were built. Besides, Ryan Dahl's idea was not using javascript on the server side. It was to build an evented server. Hence javascript choice, language offering closures that are used as continuation, and also being used for years in our browser.
Javascript has more advantages. First, Json is becoming the de facto exchange format on HTTP, and it's natively handled by Js - which is one of main reasons beyond the json takeover of xml. This is both more convenient, and more efficient.
Also, using the same language across the network enables us to reuse code or build isomorphic application. Being the predilection language of webfront developer, we can more easily have fullstack programmer than can both work with the GUI or the API.
As an open source project, it enjoys both strong community and industrial support.
Node is a living platform with its 36 thousand stars - third most popular github project - and its 148 thousand packages on NPM. It benefits from the already existing pool of javascript developers coming from the front.
Also, numerous free resources in most languages are available online. You can easily learn from blog articles which are more or less focused, along with books and dedicated courses such has nodeschool.io. Besides there is also a Node meetup in every city with an IT sector.
Though still new, node platform has already been adopted, used and tested by web giants such as Walmart, Paypal, Linkedin, Yahoo! Many cloud and virtualisation companies are backing it, such as Joyent, which fathered it.
Since our first article back in 2011 Node and its main libraries have gotten far more mature. Besides, many worldwide companies have opted for it and Node is referred has a reference stack in some CIOs has a Java replacement.
A subtle doubt was introduced by the mini-rift triggered by io.js fork in late 2014. It was caused by development cycle management and the slowness to integrate Ecma6 Harmony features. However this is (almost) already ancient history with 2015 may settlement, the two factions joining in the Node.js Foundation.
With its reactive approach and the induced performance, its quality and the strong community surrounding it, Node is a very good choice to build REST API.