Når og hvordan bruker du worker threads?

Question

Accepted Answer

**Worker threads** lar Node kjøre JavaScript på **separate tråder** med ekte parallellisme — og løser Nodes største begrensning: CPU-intensivt arbeid som blokkerer den enkelte hovedtråden (og dermed alle forespørsler). Bruk dem for tunge beregninger, ikke for I/O (som event loop allerede håndterer effektivt).

## Problemet de løser

```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 kjører JS-en din på én tråd. En lang synkron beregning blokkerer **alt** — event loop kan ikke behandle andre forespørsler før den er ferdig. Worker threads flytter det arbeidet vekk fra hovedtråden.

## Bruke en 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
```

Worker-en kjører uavhengig; hovedtråden fortsetter å betjene forespørsler og får resultatet via en melding når det er ferdig.

## Når du skal bruke (og ikke)

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

Regelen: **workers for CPU-bound, event loop for 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
```

## Hvorfor det betyr noe

Worker threads løser Nodes kjernsvakhet — CPU-bound-oppgaver som blokkerer den enkelttrådede event loop og fryser alle samtidige forespørsler.

Å vite hvordan du offloader tung beregning til en worker (holder hovedtråden responsiv), og kritisk **når** du skal bruke dem (CPU-bound bare, aldri for I/O), er det som lar en Node-tjeneste håndtere og da og når tung behandling uten å ofre parallelliteten som gjør Node verdifull.

For å samle workers i produksjon, håndterer biblioteker som Piscina en thread pool effektivt.