Node.js Event Loop: Asynchronous Execution Explained

1. Le problème : pourquoi l'asynchrone est-il nécessaire ?

Avant Node.js, la plupart des serveurs web suivaient un modèle simple mais coûteux : un thread (un processus d'exécution) par requête. Si une requête devait attendre une opération lente (lire un fichier, interroger une base de données), le thread entier était bloqué, consommant des ressources sans rien faire.

Pour comprendre la solution apportée par Node.js, je vous propose de lire les extraits d'un article qui illustre parfaitement ce problème et la solution élégante de Node.js.

La philosophie de Node.js est donc radicalement différente : ne jamais attendre. Au lieu d'un barista dédié à chaque client du début à la fin, Node.js agit comme un unique coordinateur ultra-efficace qui prend les commandes, les délègue à des "machines" (le système d'exploitation, un pool de threads), et revient servir les clients dès que leur commande est prête. Ce coordinateur, c'est l'Event Loop.

Démonstration pratique : Bloquant vs. Non-bloquant

La théorie est une chose, mais une démonstration concrète est bien plus parlante. L'article que vous venez de lire propose une expérience simple mais très révélatrice.

Le serveur bloquant (Python)
Ce serveur simule une tâche lente avec time.sleep(2). Cette fonction bloque tout le processus.

# blocking_server.py
import time
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello_world():
    print("Request received. Starting 2-second 'work'...")
    time.sleep(2) # BLOCKS the entire process!
    print("Work finished. Sending response.")
    return "Hello from the blocking server!"

if __name__ == '__main__':
    app.run(port=5000)

Le serveur non-bloquant (Node.js)
Ce serveur utilise setTimeout, qui est non-bloquant. Il planifie une tâche et rend la main immédiatement.

// non_blocking_server.js
import http from "http";

const server = http.createServer((req, res) => {
  console.log("Request received. Scheduling 2-second 'work'...");
  
  // NON-BLOCKING: schedules work and returns immediately.
  setTimeout(() => {
    console.log("Work finished. Sending response.");
    res.writeHead(200, { "Content-Type": "text/plain" });
    res.end("Hello from the non-blocking server!");
  }, 2000);
});

server.listen(5001, () => {
  console.log("Server running on http://localhost:5001/");
});

Si nous envoyons 10 requêtes en même temps à ces deux serveurs :

• Serveur bloquant : Il traitera les requêtes l'une après l'autre. Le temps total sera d'environ 20 secondes (10 requêtes * 2 secondes).
• Serveur non-bloquant : Il acceptera les 10 requêtes quasi instantanément, lancera les 10 minuteurs en parallèle, et répondra à toutes les requêtes après environ 2 secondes.

Cette différence de performance fondamentale est la raison d'être de Node.js.

2. Le mécanisme : les acteurs de l'asynchronie

Maintenant que nous avons vu le "pourquoi", explorons le "comment". Comment JavaScript, qui est fondamentalement mono-thread (single-threaded), peut-il accomplir cela ?

La magie opère grâce à la collaboration de plusieurs composants. Une vidéo animée est parfaite pour visualiser ce flux.

Résumons le flux que vous venez de voir :

1. Call Stack (Pile d'appels) : C'est là que JavaScript garde une trace des fonctions en cours d'exécution. C'est une structure de données LIFO (Last-In, First-Out).
2. Node.js APIs / libuv : Quand une fonction asynchrone (ex: fs.readFile, setTimeout, une requête à une base de données) est appelée, elle n'est pas exécutée directement par JavaScript. Elle est transmise aux APIs de Node.js, qui s'appuient sur une bibliothèque C++ nommée libuv. C'est libuv qui gère ces opérations en arrière-plan, souvent en utilisant les capacités multi-threads du système d'exploitation ou son propre pool de threads. Votre code JavaScript principal n'est donc pas bloqué.
3. Callback Queue (File d'attente des callbacks) / Task Queue : Une fois que l'opération asynchrone est terminée, la fonction de callback qui lui est associée n'est pas exécutée immédiatement. Elle est placée dans une file d'attente.
4. Event Loop (Boucle d'événements) : C'est le chef d'orchestre. Son rôle est simple mais crucial : il surveille en permanence la Call Stack et la Callback Queue. Si la Call Stack est vide, il prend le premier callback de la file et le pousse sur la pile pour exécution.

Ce cycle se répète indéfiniment, d'où le nom de "boucle".

3. Un niveau de profondeur : Microtasks et Macrotasks

Le modèle que nous venons de voir est légèrement simplifié. En réalité, il n'y a pas une, mais deux files d'attente principales qui nous intéressent :

1. Task Queue (ou Macrotask Queue) : Pour les callbacks de setTimeout, setInterval, les opérations I/O (lecture de fichier, requêtes réseau), et setImmediate.
2. Microtask Queue (ou Job Queue) : Pour les callbacks des Promises (.then, .catch, .finally) et process.nextTick().

Pourquoi cette distinction ? Parce qu'elles n'ont pas la même priorité.

La règle d'or de l'Event Loop :
Après chaque tâche exécutée depuis la Task Queue, l'Event Loop exécute TOUTES les tâches présentes dans la Microtask Queue avant de passer à la tâche suivante de la Task Queue. La Microtask Queue a donc une priorité plus élevée.

La vidéo suivante visualise très bien cette priorité.

Cette distinction est cruciale car async/await, que nous verrons bientôt, est basé sur les Promises. Comprendre que leurs opérations passent par la Microtask Queue vous aidera à déboguer des comportements asynchrones complexes.

4. Les phases de l'Event Loop de Node.js

Pour une compréhension exhaustive, utile notamment pour des entretiens techniques, il faut savoir que l'Event Loop de Node.js est officiellement décomposé en plusieurs phases distinctes qui s'exécutent dans un ordre précis à chaque "tick" de la boucle.

Voici un résumé simplifié des phases les plus importantes :

1. timers : Exécute les callbacks planifiés par setTimeout() et setInterval().
2. pending callbacks : Exécute des callbacks I/O qui ont été différés au tick précédent (cas rares).
3. idle, prepare : Phase interne à Node.js.
4. poll : La phase la plus importante. Elle récupère les nouveaux événements I/O (lecture de fichier terminée, nouvelle requête HTTP, etc.) et exécute leurs callbacks. Si la file poll est vide, la boucle attend ici ou passe à la phase check si des setImmediate sont planifiés.
5. check : Exécute les callbacks planifiés par setImmediate().
6. close callbacks : Gère les événements de fermeture (ex: socket.on('close', ...)).

Et où sont process.nextTick() et les Promises ? Ils ne font pas partie de ces phases. Leurs callbacks sont exécutés immédiatement après l'opération en cours, avant que l'Event Loop ne passe à la phase suivante. C'est pour cela qu'ils ont une priorité encore plus élevée que les callbacks de setImmediate dans la phase check.

Conclusion

Félicitations pour avoir abordé ce sujet complexe mais fondamental. Une bonne compréhension du modèle asynchrone de Node.js vous distingue en tant que développeur backend compétent.

Points clés à retenir :

• Node.js est asynchrone et non-bloquant : Il utilise un seul thread pour exécuter votre code JavaScript, il ne faut donc jamais le bloquer avec des opérations longues et synchrones.
• L'Event Loop est le chef d'orchestre : Il permet à Node.js de déléguer des tâches lentes à libuv (qui peut utiliser d'autres threads) et d'exécuter les callbacks correspondants lorsque les tâches sont terminées et que la pile d'appels est vide.
• Deux types de files d'attente : La Microtask Queue (pour les Promises) est prioritaire et est entièrement vidée après chaque tâche de la Task Queue (pour setTimeout, I/O).
• Le modèle est une collaboration : V8 (moteur JS), libuv (gestion de l'asynchrone), les APIs Node.js et l'Event Loop travaillent tous ensemble pour créer ce modèle performant.

Dans nos prochaines leçons, nous allons arrêter de nous concentrer sur le comment ça marche pour nous focaliser sur le comment l'utiliser. Nous commencerons par maîtriser les Promises, le mécanisme standard pour gérer les opérations asynchrones en JavaScript moderne.