JavaScript côté serveur

Vous avez une API à écrire. Elle reçoit une requête HTTP, interroge une base PostgreSQL, appelle deux services externes, agrège les réponses et renvoie du JSON. Sur les 180 millisecondes que dure ce traitement, le processeur travaille peut-être 4 millisecondes. Tout le reste, c'est de l'attente : le réseau, le disque, la base. Un serveur classique qui alloue un fil d'exécution par requête garde donc 176 millisecondes de mémoire de pile immobilisée à ne rien faire, multipliées par le nombre de requêtes simultanées. À mille connexions actives, cela devient un problème de gigaoctets et de changements de contexte.

Node.js part de l'observation inverse : puisque le serveur passe son temps à attendre, autant n'avoir qu'un seul fil d'exécution qui traite les événements au fur et à mesure qu'ils sont prêts. Une requête qui attend la base n'occupe pas un fil, elle occupe une entrée dans une table de rappels, c'est-à-dire quelques centaines d'octets. C'est ce compromis, et lui seul, qui explique à la fois pourquoi Node encaisse très bien les charges de type entrées-sorties et pourquoi il s'effondre dès qu'un calcul un peu long s'installe dans le fil unique. Comprendre ce marché avant d'écrire la première ligne vous évitera la moitié des ennuis de production.