Beaucoup de connexions en même temps, peu de machine

Attendre sans bloquer

La plupart du temps, un serveur d’application attend : une base de données, un service externe, un fichier. Dans le modèle classique, chaque requête occupe un processus pendant cette attente, et il faut donc autant de processus que de requêtes en cours.

Node.js prend le problème autrement : un seul processus gère des milliers de connexions en attente, et ne travaille que lorsqu’une réponse arrive. C’est pourquoi nous l’employons principalement sur les projets qui doivent traiter un nombre important de requêtes simultanées — passerelles d’API, applications temps réel, services qui interrogent beaucoup d’autres services.

Le corollaire vaut d’être dit : sur un calcul lourd et continu, ce modèle n’apporte rien, et un autre langage sera plus adapté.

Un seul langage, du serveur au navigateur

C’est l’argument le plus concret au quotidien. Le même TypeScript décrit les données côté serveur et côté navigateur : les mêmes types, les mêmes règles de validation, la même équipe. On supprime toute une catégorie de bugs — ceux où les deux côtés ne s’entendent pas sur la forme d’un objet — et on ne double pas les compétences nécessaires.

Ce que nous en faisons

Comme PHP, Node.js permet de créer des sites, des applications et des boutiques en ligne. On le trouve aussi souvent dans la mouvance des CMS headless, que nous avons également adoptée : c’est ce qui fait tourner la génération d’un site Astro ou Gatsby, et les services qui alimentent une vitrine découplée.

Ce qu’il coûte en hébergement

Une application Node.js est un programme qui tourne en permanence, pas un script appelé à chaque visite. Elle ne peut donc pas vivre sur une plateforme mutualisée : il lui faut une machine, ou un conteneur. C’est le principal écart de coût avec une application PHP, et il faut l’avoir en tête au moment de choisir — nous le disons avant le devis, pas après.