Why use Node to build my API?

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?

A powerful technology for the Web

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.

Non blocking IO

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.

Reactive approach

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.

Lightweight and high-performance

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.

A productive and industrialised Stack

Unix-like Philosophy

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.

Tools to handle and share packages

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! ».

Javascript at the heart of platform success.

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.

A strong and growing community

As an open source project, it enjoys both strong community and industrial support.

Community

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.

Industrial support and use

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.

Go for Node

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha

Pourquoi utiliser Node pour réaliser mon API ?

Ces dernières années l’approche REST devient l’architecture incontournable des API en utilisant la puissance du protocole HTTP. Parallèlement on assiste à une reconfiguration du paysage côté serveur notamment avec la percée de Node.js

Node s’est imposé comme une des principales piles techniques. S’il permet facilement de créer un petit serveur HTTP en une ligne de commande, qu’en est-il pour une API d’envergure? (suite…)

8 commentaires sur “Pourquoi utiliser Node pour réaliser mon API ?”

  • IO Non bloquants => must have. Il aurait été sympas d'avoir quelques exemples :) Très bon article, sinon. Bonne journée ! Olivier
  • Bonjour, Node n'a pas le monopole de l'approche réactive ! Il y a par exemple en Java plusieurs choix disponibles : il n'y a pas que JEE dans la vie (voir Vert.x, ...) Quant à la performance supposée meilleure de Node, un benchmak récent comme celui de TechEmpowers (voir http://www.techempower.com/benchmarks/) montre que Node est plutôt médiocre. Sans accorder un crédit sans borne aux benchmarks, techEmpowers est tout de même une référence : l'avantage de Node en terme de performance ne saute pas du tout aux yeux. La seule force de Node il me semble réside surtout dans la possibilité de mutualiser du code entre le client et le serveur mais à quel prix tant le langage est permissif et souffre de manques cruels (annotation, ...). Le langage est cependant en train d'évoluer. Cdlt.
  • Juste pour relever une petite faute à corriger. "De plus node.js est nait de la volonté..."
  • Merci ! C'est corrigé ;)
  • Pour illustrer mon propos précédent : Java vs NodeJS http://blog.n-k.de/2015/01/high-performance-microservices-nodejs.html
  • Bonjour Septic :) Loin de moi suggérer que Node a un tel monopole. Au contraire! Il y a des très bonnes solutions dans le monde JVM pour faire du réactif au sens large avec Clojure et Scala. Et puis Java ne se réduit pas à JEE, et a les bibliothèques asynchrones qu'il faut. Autant nous pensons que l'API devient indispensable, autant nous sommes ouvert sur le langage et la stack utilisée: cela n'est presque pas important. Nous avons de bon REX sur la mise en oeuvre d'API d'envergure en Node, mais : It doesn't matter which technology you use - use it right!. En effet, Node n'est pas ni un silver bullet, ni un golden hammer. Bon weekend à tous :)
  • Article très intéressant ! Mais puisqu'il s'agit de de convaincre d'utiliser Node.js pour des API, il serait intéressant de parler d'autres languages. Par exemple en PHP avec Symfony2, Python avec Django etc. Personnellement j'apprécie beaucoup Node, mais j'attend encore d'avoir un framework/plugin permettant de faire l'équivalent de DunglasApiBundle sur Symfony2 pour les API !
  • L’immense avantage de node.js par rapport aux autres langages est que toutes les plateformes Cloud offre toujours une API en Node.js, donc c’est le seul langage qui autorise une véritable interopérabilité avec toutes les plateformes Cloud (SAP, Azure, Google, Amazon, IBM…). C’est normal parce que Node.js = JavaScript = Web = Web Browsers = HTML5 = interopérabilité. Actuellement je regarde Node-Red ( http://nodered.org/ ) qui est une merveille de puissance et de simplicité pour faire de l’IoT avec n’importe qu’elle plateformes Cloud/Web.
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha