Quand et comment utilisez-vous les worker threads ?

Question

Accepted Answer

**Les worker threads** permettent à Node d'exécuter JavaScript sur **des threads séparés** avec un vrai parallélisme — résolvant la plus grande limitation de Node : les tâches gourmandes en CPU qui bloquent le seul thread principal (et donc toutes les requêtes). Utilisez-les pour les calculs lourds, pas pour les I/O (que la boucle d'événements gère déjà efficacement).

## Le problème qu'ils résolvent

```js
// ❌ this CPU-heavy work BLOCKS the event loop → all requests freeze for its duration
app.get("/hash", (req, res) => {
  const result = expensiveComputation(); // e.g. heavy crypto, image processing
  res.json(result); // meanwhile, no other request can be handled
});
```

Node exécute votre JS sur un seul thread. Un long calcul synchrone bloque **tout** — la boucle d'événements ne peut pas traiter d'autres requêtes avant sa fin. Les worker threads déplacent ce travail hors du thread principal.

## Utilisation d'un worker thread

```js
// main.js
import { Worker } from "worker_threads";

// the main thread stays free to handle other requests while this runs
const result = await runHeavyTask({ numbers: [...] });
```

```js
// worker.js — runs in parallel, on its own thread
import { workerData, parentPort } from "worker_threads";

const result = expensiveComputation(workerData); // doesn't block the main thread
parentPort.postMessage(result);                    // send the result back
```

Le worker s'exécute indépendamment ; le thread principal continue à servir les requêtes et reçoit le résultat via un message une fois terminé.

## Quand utiliser (et ne pas utiliser)

```text
✓ USE for CPU-bound work: image/video processing, encryption, compression,
  big data parsing, complex calculations, ML inference
✗ DON'T use for I/O (DB, files, HTTP) — the async event loop already handles
  that efficiently; a worker would add overhead for no benefit
```

La règle : **worker threads pour les tâches CPU-bound, boucle d'événements pour les tâches I/O-bound.**

## Worker threads vs child_process vs cluster

```text
worker_threads → share memory (efficient data passing), in-process threads — CPU work
child_process  → separate OS processes, run other programs — heavier isolation
cluster        → fork the whole server across CPUs — scale request handling
```

## Pourquoi c'est important

Les worker threads adressent la faiblesse fondamentale de Node — les tâches CPU-bound qui bloquent la boucle d'événements monothread et gèlent toutes les requêtes concurrentes.

Savoir déléguer les calculs lourds à un worker (en gardant le thread principal réactif), et surtout **quand** les utiliser (CPU-bound uniquement, jamais pour l'I/O), permet à un service Node de gérer un traitement lourd occasionnel sans sacrifier la concurrence qui fait la valeur de Node.

Pour mettre en commun les workers en production, des bibliothèques comme Piscina gèrent efficacement un pool de threads.