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?

Une technologie performante pour le Web

Si Node.js a su percer dans le domaine des applications web, c’est en partie parce que celui-ci a introduit un changement de paradigme par rapport aux stacks classiques, « révolution » à l’origine de gains de performances notables.

IO Non bloquants

Au coeur de l’architecture node.js on retrouve des opérations IO non bloquantes, que ce soit à propos des interactions réseaux, ou de toutes les autres formes d’entrées/sorties, notamment le système de fichiers et les différentes bases de données aujourd’hui disponibles. Ceci est crucial sachant que pour des applications web, ce sont ces entrées sorties qui sont le facteur limitant. (Ce que l’on dénote par IO-bound dans la littérature anglaise). La latence introduite par ces opérations est de plusieurs ordres de grandeur supérieure à celle des autres calculs dans le processeur. Avec des opérations bloquantes le thread appelant l’opération serait inactif la plupart du temps.

C’est cet ensemble de bibliothèques IO non bloquantes, HTTP et autres protocoles de plus bas niveau (tcp, udp) que Node introduit au dessus du moteur JavaScript v8. Ces opérations non bloquantes fonctionnent de la manière suivante: on leur passe en argument le calcul qui devra être effectué sur le résultat; la fonction retourne immédiatement et notre fonction – appelée continuation, callback, ou fonction de rappel – sera invoquée une fois l’opération terminée.

Approche Reactive

De pair avec les IO non bloquant, on retrouve une approche réactive bien décrite plus en détail dans cet article sur le modèle réactif et intrinsèque à javascript et node.

Elle est implémentée par la boucle d’événements au coeur de node qui va continuellement traiter les événements avec les continuations associées. C’est le même schéma qui est utilisé par les serveurs hautes performances comme Nginx et qui permet de servir simultanément nombre de requêtes avec un seul thread.

Concrètement le serveur conserve une pile de fonctions à exécuter à la reception d’événements, et l’unique thread va ainsi traiter les événements les uns après les autres.

Vecteur de performance

L’approche événementielle couplée à des IO non bloquant font qu’il n’y a plus besoin de plusieurs threads pour traiter des requêtes de manière concurrente. Ceci permet d’économiser en changements de contexte, et overheads qu’entraîne la gestion de plusieurs threads. De plus le thread processus restant est utilisé au maximum possible, se chargeant de traiter de manière continue les événements apparaissant dans la queue d’événements au fil des requêtes et fin d’IO. Attention par contre à ne pas bloquer la boucle d’événement avec des opérations gourmandes en CPU ce qui dilapiderait tout ces bénéfices.
Cet usage optimisé du materiel nous permet d’utiliser des serveurs plus léger sans avoir à sacrifier la performance aux yeux de l’utilisateur et ainsi traiter des milliers de requêtes simultanées, avec une empreinte mémoire faible.

Couplé à cela, l’absence d’état partage nous dispensant de synchronisation entre threads, il est plus facile de répliquer l’application sur plusieurs nœuds (node en anglais…) qui se verront répartir les requêtes par un répartiteur de charge. Node.js permet ainsi facilement un passage à l’échelle de manière horizontale, avec du commodity hardware. C’est-à-dire des serveurs aux coûts maîtrisés et faciles à obtenir notamment avec les solutions cloud IAAS et PAAS (à la Aws et Heroku), contrairement aux traditionnels serveurs d’application comme WebSphere et WebLogic.

Une technologie productive et industrialisée

La simplicité au coeur, Philosophie et Architecture

Au coeur de la philosophie de node.js, on retrouve la simplicité, le coeur de node offrant une API simple. Les applications sont structurées en modules de taille modeste et réutilisable, se concentrant sur une fonctionnalité dans la lignée de la philosophie Unix venant enrichir le coeur de node.

Le fait que le node.js ait une portée minimale favorise la maintenabilité et la réutilisabilité ce qui s’est reflété dans la culture de l’écosystème node où de nombreux bibliothèques, packages ont émergé suivant la même philosophie.

Un Outillage pour gérer et partager les dépendances

Pour éviter un enfer des dépendances, au nombre multiplié par la taille des packages, l’environnement node est doté de l’outil npm, Node Packet Manager. La description d’un paquet se fait à l’aide du package.json, standard qui va décrire le package réalisé ainsi que les dépendances de celui-ci. Ceci favorise la réutilisation du code, mais aussi permet un partage facile du code développé auprès de la communauté.

Grâce à cette bonne gestion de paquets avec npm, des collections de librairies sont disponibles, bien pensées, collectivement développées, performantes, et éprouvées par un grand nombre d’utilisateurs. La quantité de modules disponibles est considérable, la plupart des besoins étant satisfaits. Comme nous le pointions déjà dans notre article sur les débuts de Node, « Il y a un module pour ça ».

Javascript au coeur du succès de la plateforme

Certes le langage est loin d’être parfait, mais il est en voie d’être amélioré par les nouvelles versions à venir d’EcmaScript. De plus node.js est né de la volonté de faire un serveur à boucle d’événement, et non de l’envie de faire du javascript coté serveur. Une des principales raisons est la part des fermetures dans le langage, et de leur utilisation en tant que continuation. Bien entendu, l’approche événementielle de node.js n’est pas éloignée de celle du moteur de nos navigateurs et sa boucle d’événements asynchrones.

Au-delà de ce choix initial, javascript apporte de nombreux avantages. Tout d’abord JSON est devenu le format d’échange standard sur HTTP, celui-ci est nativement géré en javascript, nous épargnant le temps de parsage ou serialisation. Aussi l’utilisation du même langage des deux côtés du réseau nous permet une certaine réutilisation de code, sans aller jusqu’à parler d’isomorphisme. En tout cas, JavaScript est incontestablement le langage de prédilection des développeurs « full stack » qui peuvent intervenir sur la partie IHM (front) et sur la partie API (back) de manière indifférenciée.

Une communauté active et qui mûrit vite

Node en tant que projet open source bénéficie aussi à la fois d’un fort soutien communautaire, mais aussi d’un bon support industriel.

Communauté

La plateforme est bien vivante avec ses 36 mille étoiles, qui font de node.js un des projets github les plus populaires, et ses 148 milles paquets sur NPM. Elle a aussi su bénéficier du vivier déjà existant de développeurs javascript venus du front. De plus, de nombreuses ressources sont disponibles en ligne pour l’apprendre que ce soit articles plus ou moins spécialisés, mais aussi cours dédiés comme sur nodeschool.io.

Support et utilisation industrielle

Bien que relativement jeune, la plateforme Node a déjà été adoptée, utilisée et éprouvée par des grands du Web comme Walmart, Paypal, Linkedin, Yahoo! Elle est soutenue par plusieurs compagnies dans le domaine de la virtualisation et du cloud computing dont Joyent d’où il a émergé.

Depuis notre premier article en 2011 node et ses principales librairies ont fortement gagné en maturité. L’utilisation en industrie a aussi suivi de nombreuses compagnies ayant fait le saut. Avec l’engouement pour les API, Node est aujourd’hui désigné comme stack de référence au sein de plusieurs DSI, en remplacement de Java.

Un léger doute a été introduit par le minischisme engendré par le fork du projet autour de io.js en réaction notamment à la gestion du cycle de développement et la lenteur de l’intégration d’EcmaScript 6 Harmony. Ce schisme qui est d’ailleurs en train de se résorber au moment de la finalisation de cet article.

Go for Node

L’approche réactive et la performance qu’elle entraîne, doublée d’une plateforme bien construite et soutenue par une forte communauté font de Node un très bon choix pour la réalisation d’une API REST.

 

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