L'architecture de Node.js : V8, libuv et entrées / sorties non bloquantes

Une analogie : le serveur du restaurant

• Imaginez un restaurant avec un seul serveur. Il prend la commande de la table 1, la transmet à la cuisine, puis… il ne reste pas planté devant la cuisine à attendre. Il va prendre la commande de la table 2, puis de la table 3. Quand un plat est prêt, la cuisine sonne : il l'apporte à la bonne table.
• Node.js fonctionne exactement ainsi :
  • le serveur, c'est le fil d'exécution unique qui exécute votre code JavaScript ;
  • la cuisine, c'est le système d'exploitation et libuv, qui lisent les fichiers et attendent les réponses du réseau ou de la base de données ;
  • la sonnette, c'est un événement: « le fichier est lu », « la requête est arrivée », « la base a répondu » ;
  • la façon dont le serveur choisit sa prochaine tâche, c'est la boucle d'événements.
• Un restaurant « bloquant » aurait besoin d'un serveur par table, chacun attendant devant la cuisine. Ça fonctionne, mais cela coûte beaucoup plus cher.

Les composants de Node.js

• Votre application: votre code JavaScript et les paquets npm que vous utilisez.
• L'API de Node.js: les modules fournis avec Node.js, écrits en JavaScript : fs (fichiers), http (serveur web), path (chemins), events (événements), stream (flux), crypto (chiffrement), os (système).
• Les liaisons C++ (bindings) : elles relient ces modules JavaScript au code natif, écrit en C et C++.
• V8: le moteur JavaScript de Google. Il compile votre JavaScript en code machine et gère la mémoire (allocation, ramasse-miettes). V8 ne sait rien des fichiers ni du réseau : il exécute seulement du JavaScript.
• libuv: une bibliothèque écrite en C. C'est elle qui fournit la boucle d'événements et les entrées / sorties asynchrones, de la même façon sous Windows, Linux et macOS. Pour les opérations que le système ne sait pas faire de façon asynchrone (certaines lectures de fichiers, le chiffrement, la compression), libuv utilise un petit pool de threads: 4 par défaut.

Bloquant ou non bloquant ?

• Une opération bloquante (synchrone) arrête le programme jusqu'à ce qu'elle soit terminée. Une opération non bloquante (asynchrone) est lancée, puis le programme continue ; son résultat est traité plus tard, par une fonction de rappel (callback), une promesse ou await.
• Comparez ces deux programmes, qui lisent le même fichier :

// bloquant.js : lecture SYNCHRONE, le programme attend
import { readFileSync } from 'node:fs';

console.log('1. Début');
const contenu = readFileSync(import.meta.filename, 'utf8');
console.log(`2. Fichier lu : ${contenu.length} caractères`);
console.log('3. Fin');

1. Début
2. Fichier lu : 266 caractères
3. Fin

// non-bloquant.js : lecture ASYNCHRONE, le programme continue
import { readFile } from 'node:fs';

console.log('1. Début');
readFile(import.meta.filename, 'utf8', (erreur, contenu) => {
  if (erreur) throw erreur;
  console.log(`3. Fichier lu : ${contenu.length} caractères`);
});
console.log('2. Fin du code principal');

1. Début
2. Fin du code principal
3. Fichier lu : 323 caractères

Pourquoi c'est si important pour un serveur

• Un serveur web passe l'essentiel de son temps à attendre: la base de données, un fichier, une API externe. Pendant cette attente, un serveur non bloquant peut traiter d'autres requêtes :

• Ce script simule trois requêtes d'une seconde chacune. On les traite d'abord l'une après l'autre, puis toutes en même temps :

// attente.js : 3 « requêtes » de 1 seconde chacune
const requete = (nom) =>
  new Promise((resolve) => setTimeout(() => resolve(`${nom} terminée`), 1000));

console.time('en série');
await requete('R1'); await requete('R2'); await requete('R3');
console.timeEnd('en série');

console.time('en parallèle');
const resultats = await Promise.all([requete('R1'), requete('R2'), requete('R3')]);
console.timeEnd('en parallèle');
console.log(resultats);

en série: 3.004s
en parallèle: 1.002s
[ 'R1 terminée', 'R2 terminée', 'R3 terminée' ]

La boucle d'événements en bref

• Quand vous lancez node app.js, Node.js exécute d'abord tout le code du fichier, de haut en bas. Ensuite, tant qu'il reste quelque chose à attendre (un minuteur, un serveur qui écoute, une lecture en cours), la boucle d'événements tourne. À chaque tour, elle :
  1. exécute les minuteurs arrivés à échéance (setTimeout, setInterval) ;
  2. récupère les entrées / sorties terminées (fichier lu, requête reçue) et exécute leurs fonctions de rappel ;
  3. exécute les rappels programmés avec setImmediate;
  4. entre chaque étape, vide la file des promesses résolues (les « microtâches »).
• Quand il n'y a plus rien à attendre, le programme s'arrête. C'est pourquoi un script simple se termine tout seul, alors qu'un serveur reste actif : il attend des requêtes.
• Vous étudierez la boucle d'événements en détail au chapitre 5. Pour l'instant, retenez l'ordre : code synchrone d'abord, puis promesses, puis minuteurs et entrées / sorties.

Ce qui bloque un serveur Node.js

• Le revers du fil unique : si votre code JavaScript fait un long calcul, plus rien d'autre ne s'exécute. Dans ce serveur, l'adresse /calcul fait une boucle de 3 milliards de tours :

// bloque-boucle.js : un calcul long bloque TOUT le serveur
import http from 'node:http';

http.createServer((requete, reponse) => {
  if (requete.url === '/calcul') {
    let somme = 0;
    for (let i = 0; i < 3e9; i++) somme += i;   // plusieurs secondes de calcul
    return reponse.end(`Somme : ${somme}\n`);
  }
  reponse.end('Réponse immédiate\n');
}).listen(3000, () => console.log('http://localhost:3000'));

• dans un serveur, utilisez toujours les versions asynchrones (readFile, fs/promises) ; les versions …Sync sont réservées aux scripts et au démarrage ;
• ne faites jamais de long calcul dans une requête : découpez-le, confiez-le à un worker_thread, ou à un autre service ;
• attention aux boucles sur des tableaux de millions d'éléments et aux expressions régulières mal écrites, qui peuvent bloquer le serveur.