Node.js, JavaScript côté serveur

En attente du prochain grand language (NBL pour Next Big Language), cela fait maintenant 3 ans que je prédis à mes clients un bel avenir au JavaScript comme langue de programmation pour les applications serveurs. Mon argumentation se fondait essentiellement sur son esthétisme, sa simplicité et sa nature dynamique. Conçu en 1995 par Sun Microsystems (racheté par Oracle) et Netscape (racheté par AOL), son intégration dans les navigateurs Internet a largement diffusé le langage mais ce n’est qu’à partir de 2004 au travers de la génération AJAX et d’applications Web telles que Gmail et Google Maps que le langage a reçu ses lettres de noblesse et gagna l’attention des professionnels.

Malgré quelques efforts infructueux, son utilisation était cantonnée aux postes clients, c’est à dire aux navigateurs Internet dans lesquels il permet de dynamiser les pages Web. Depuis quelques années, des solutions sont apparues dans la communauté Open Source. Je pense notamment à Helma, d’un fonctionnement traditionnel au sein d’une machine virtuelle Java et donc aisément intégrable au large écosystème Java, mais aussi à des solutions plus innovantes comme Jaxer, dont la particularité est de créer un environnement de type navigateur (comme la manipulation du DOM) sur le serveur. De tous, c’est sans doute Narwhal qui me laissa la plus forte impression par son architecture simple et la modularité de l’interpréteur JavaScript.

Durant ces dernières années, j’ai suivi avec attention l’actualité autour des solutions serveurs, testant chacune d’entre elles et analysant leurs approches. Au vu du trafic généré par chaque article traitant du sujet, je m’aperçus à cette occasion que je n’étais pas isolé. Mais aucun des projets n’avait pu me convaincre d’abandonner ce mauvais garçon qu’est PHP. Jusqu’à il y a quelques mois avec l’apparition de NodeJs.

Revenons un peu en arrière. L’AJAX marqua l’importance et le besoin de performance des navigateurs et l’interpréteur JavaScript est une donnée essentielle des applications Internet dites riches (RIA pour Rich Internet Application). Les éditeurs Mozilla et Microsoft rejoints par Apple avec Safari et plus récemment Google avec Chrome se sont lancés dans une course à l’optimisation. Cette saine compétition a donné naissance à de nouvelles générations d’interpréteurs que sont TraceMonkey pour Firefox 3.6, SquirrelFish pour Safari 5, Carakan pour Opera et V8 pour Chrome. Longtemps à la traîne, même Microsoft se prend au jeu dans la version 9 d’Internet Explorer. Aujourd’hui, le JavaScript est sans nul doute le langage concentrant l’essentiel des efforts de développement.

Mais il y a une autre raison pour laquelle JavaScript est rapide et un excellent choix côté serveur. Par nature, c’est un langage orienté évènement en opposition aux serveurs orientés thread. Cette caractéristique du langage vient de ses origines où il était destiné à fonctionner à l’intérieur des navigateurs Internet et il était essentiel de supporter les évènements utilisateurs sans saturer l’ensemble du navigateur à chaque action. Traditionnellement, les applications serveurs sont écrites sous un mode thread dit bloquant. C’est le cas pour les applications PHP et CGI et l’essentiel des applications Python, Ruby ou Java.

Je vais essayer d’être aussi clair que possible. Lorsqu’un serveur reçoit une requête, par exemple l’envoi d’un formulaire, le serveur met à disposition une thread et lance l’application qui effectue ses opérations les une après les autres (connexion à une base de données afin de valider le nom et le mot passe de l’utilisateur, écriture dans un fichier de log,…) avant de finalement retourner la réponse au formulaire et de fermer la thread. Or le nombre de thread est limité et ces applications génèrent rapidement des erreurs lorsque celles-ci arrivent à saturation de la mémoire. Chaque thread est monopolisée jusqu’à la fin de l’ensemble des opérations. Ces opérations comme l’écriture d’un fichier prennent énormément de temps en comparaison de la vitesse d’un CPU et ce n’est que pur gâchis. Pour les applications avec de forts volumes de trafic, chaque requête doit être codée pour être la plus courte possible. Contrairement, dans un environnement évènementiel, ces mêmes opérations sont dites non bloquantes car en attendant de requêter sur une base de données ou d’écrire dans un fichier, le serveur peut continuer à effectuer d’autres tâches dans une même thread.

L’absence d’alternative non bloquante peut même devenir handicapante pour certains scénarios tels que le téléchargement de fichiers volumineux, le regroupement de résultats en provenance de plusieurs backends et, non des moindres, le support du protocole Bayeux (Comet) ouvrant les voix du HTTP push.

Partant du postulat que l’essentiel du temps des applications serveurs est dépensé à attendre les résultats des opérations I/O (accès réseaux vers bases de données, lecture et écriture sur le système de fichier,…), la programmation évènementielle est particulièrement adaptée à l’environnement serveur. Twisted en Python et EventMachine en Ruby répondent à cette problématique mais aucun ne bénéficie de la force d’un langage intégrant nativement ces fonctionnalités.

Revenons à Node. Décrit par son auteur comme une excellente fondation au développement d’applications Web, il est basé sur le moteur JavaScript V8 développé, utilisé et open-sourcé par Google pour son navigateur Chrome. Celui-ci est l’un des plus rapide du marché (pour ne pas dire le plus rapide) et s’améliore à chaque nouvelle version. Tout dans le développement de Node est construit et optimisé dans une optique évènementielle ce qui réduit considérablement les possibilités d’écrire une application lente parce que faisant appel à des opérations I/O bloquantes. Rapidement, la communauté Open Source a reconnu le potentiel de cette plateforme et un riche écosystème se construit autour comprenant drivers (CouchDB, MongoDB, Redis,…), libraries (Haml, Sass, Expresso, …) et frameworks (Connect, Express, …).

Pour le compte d’un client, j’ai prototypé une application et la prise en main est rapide, simple et intuitive. Le code est élégant, court et lisible. Tout ce que j’attendais des promesses du JavaScript côté serveur. Pour la réalisation du proto et malgré la jeunesse de l’écosystème, je n’ai eu à manquer de rien. Voir cela m’a permis d’utiliser des concepts empruntés des univers Ruby et Python qui font défaut à celui de PHP (une pensée particulière pour SASS). Pour ceux familiers dans le développement d’applications clients riches en JavaScript, la transition sera quasiment instantanée.

Pour résumer Node en quelques phrases :

• JavaScript est fait pour l’évènementiel : la programmation par callback est familière aux développeurs d’applications AJAX et, pour se faire, la syntaxe des fonctions anonymes et le support des closures est adapté et élégant.
• Node est construit sur Javascript : de par sa présence dans les navigateurs, c’est peut-être le langage le plus programmé au monde et bénéficie de 15 ans d’expérience.
• Node se stabilise : l’API de Node gagne en maturité et est proche de se finaliser.
• Node a un écosystème : de nombreuses librairies sont disponibles, toutes en Open Source, de nouvelles apparaissent et toutes partagent une bonne qualité de réalisation.
• Node est simple et petit : la documentation se promène d’un seul regard et permet de rapidement connaitre ses fonctionnalités.
• Node est rapide : le moteur V8 et l’architecture non bloquante en font l’une des architectures les plus puissante du marché, spécialement pour les requêtes longues et intensives en I/O.