Quando e como você usa worker threads?

Question

Accepted Answer

**Worker threads** deixam o Node executar JavaScript em **threads separadas** com verdadeiro paralelismo — resolvendo a maior limitação do Node: trabalho CPU-intensivo bloqueando a única thread principal (e assim todas as requisições). Use-os para computação pesada, não para I/O (que o event loop já trata eficientemente).

## Por que isso importa

```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 executa seu JS em uma thread. Uma computação síncrona longa bloqueia **tudo** — o event loop não consegue processar outras requisições até terminar. Worker threads movem esse trabalho para fora da thread principal.

## Usando uma 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
```

O worker executa independentemente; a thread principal continua servindo requisições e obtém o resultado via mensagem quando termina.

## Quando usar (e quando não)

```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
```

A regra: **workers para CPU-bound, event loop para 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
```

## Por que isso importa

Worker threads abrangem a fraqueza central do Node — tarefas CPU-bound bloqueando o event loop single-threaded e congelando todas as requisições concorrentes.

Saber como offload pesadas computações para um worker (mantendo a thread principal responsiva) e crucialmente **quando** usá-los (CPU-bound apenas, nunca para I/O), é o que deixa um serviço Node lidar com processamento pesado ocasional sem sacrificar a concorrência que torna Node valioso.

Para agrupamento de workers em produção, bibliotecas como Piscina gerenciam um pool de threads eficientemente.