Workers mélyebben: runtime, limitek, lokális fejlesztés

2.1A runtime közelről: handlerek az Express-app helyett

Egy Express-appban van egy hosszú életű processz, ami app.listen(3000)-rel portot nyit, és middleware-láncokon át kezel mindent. A Workernél nincs „listen": a runtime (a nyílt forráskódú workerd) eseményekkel hívja meg a kódodat. Amilyen típusú eseményre exportálsz handlert, olyanra reagál a Workered:

export default {
  // HTTP kérés — az Express route-ok helyett
  async fetch(request, env, ctx) { return new Response("hello"); },

  // ütemezett futás — a cron/EventBridge helyett (7. modul)
  async scheduled(event, env, ctx) { /* napi riport, cleanup… */ },

  // üzenetsor-fogyasztás — az SQS consumer helyett (7. modul)
  async queue(batch, env, ctx) { /* batch.messages feldolgozása */ },
};

Vagyis ami az AWS-en három külön deploy-egység lenne (web app + cron Lambda + SQS consumer Lambda), az itt lehet egyetlen Worker három handlerrel — közös kóddal, közös bindingokkal.

A harmadik paraméter, a ctx (ExecutionContext) a Worker-életciklus kulcsa. Alapszabály: amint a fetch visszaadja a Response-t, a runtime lezárhatja a munkát. Ha a válasz után még dolgozni akarsz — log kiírása, analitika, cache-frissítés —, azt a ctx.waitUntil()-lal kell „életben tartanod":

async fetch(request, env, ctx) {
  const data = await handleRequest(request, env);

  // a választ NEM késlelteti, de a runtime megvárja a hátteret:
  ctx.waitUntil(logToAnalytics(env, request, data));

  return Response.json(data);
}

2.2Compatibility date: a runtime „verziószáma"

Beanstalkon te döntöd el, mikor lépsz Node 20-ról 22-re — platform-frissítéskor minden viselkedésváltozást egyszerre kapsz meg. A Workers ehelyett compatibility date-tel dolgozik: a konfigban rögzített dátum azt mondja meg, hogy a runtime melyik napi viselkedését kéred. A Cloudflare folyamatosan frissíti a platformot, de a változtatásokat dátumhoz (vagy explicit compatibility flaghez) köti — a te Workered viselkedése soha nem változik meg alattad, amíg a dátumot nem emeled. Ez a „soha nem törünk el élő appot" garancia platform-szinten.

2.3Mennyi Node-kódom működik? — a nodejs_compat réteg

Ez a te szempontodból az egyik legfontosabb kérdés, hiszen évek npm-függősége jön veled. A helyzet 2026-ban sokkal jobb, mint a Workers hírneve alapján gondolnád. A nodejs_compat flag bekapcsolásával a Node API-k nagy része natívan, a runtime-ban implementálva elérhető, a maradékot pedig a Wrangler polyfillekkel (unenv) hidalja át bundle-öléskor.

{
  "compatibility_date": "2026-08-02",
  "compatibility_flags": ["nodejs_compat"]   // ennyi — a többit a Wrangler intézi
}

2.4Limitek: CPU-idő vs. fali idő — az új gondolkodás

A legfontosabb fogalompár, amit meg kell szokni: a Workers nem azt méri (és számlázza), meddig él a kérésed, hanem hogy mennyit dolgozik közben a CPU. Amíg a Worker adatbázisra, fetch-re vagy R2-re várakozik, az nem számít CPU-időnek — és nem is kerül pénzbe.

A fontosabb határok (Paid plan, ami éles rendszerhez reális):

A limiteket lefelé is állíthatod védelemként (elszabadult kód vagy költség ellen), felfelé pedig a konfigban:

{
  "limits": {
    "cpu_ms": 300000,      // 5 perc — pl. nehéz feldolgozáshoz
    "subrequests": 50000   // ha sok szolgáltatáshívásod van
  }
}

Ha egy Worker túllépi a CPU-limitet, a kliens 1102-es hibát kap (exceededCpu a metrikákban). A megoldási sorrend: profilozd (DevTools CPU-profil), optimalizálj, vagy szervezd ki a nehéz munkát — Queues-ba, Workflows-ba, Durable Objectbe (7. modul), végső esetben Containersbe. A 128 MB memóriára pedig a streaming a válasz: a Response body lehet stream, tehát egy nagy R2-fájlt úgy szolgálsz ki, hogy soha nincs egyben a memóriában.

2.5Lokális fejlesztés: wrangler dev, Vite plugin, Miniflare

Beanstalk-világban a „lokális fejlesztés" gyakran azt jelenti: fut a Node lokálisan, de az SQS-t, S3-at mockolod, vagy dev-AWS-fiókra csatlakozol. A Workers-nél a helyzet jobb, mert maga a runtime fut a gépeden: a wrangler dev ugyanazt a workerd motort indítja el lokálisan (ezt a becsomagolást hívják Miniflare-nek), a bindingokkal együtt:

# lokális dev szerver: http://localhost:8787
npx wrangler dev

# a KV, D1, R2, Queues bindingok LOKÁLIS szimulációval mennek,
# perzisztens állapotuk a .wrangler/state mappába kerül

# ha éles erőforrások ellen akarsz fejleszteni:
npx wrangler dev --remote

• wrangler dev — az alap: lokális workerd, szimulált bindingok, azonnali reload. A lokális D1 egy igazi SQLite-fájl, a lokális R2 a diszkre ír — offline is fejlesztesz.
• Cloudflare Vite plugin — frontend-keretrendszeres (nálad: Nuxt) projekthez ez lesz a napi eszközöd: a megszokott Vite dev szerver + HMR, de a szerveroldali kód ténylegesen a workerd runtime-ban fut, nem Node-ban — így ami lokálisan megy, az élesben is menni fog. Részletesen a 3. modulban.
• .dev.vars — lokális secretek fájlja (a .env megfelelője), git-ignore-olva; élesben a wrangler secret put az útja (8. modul).
• wrangler types — legenerálja az Env TypeScript-típusát a konfigod bindingjaiból, tehát az env.MY_BUCKET típusos lesz.

2.6Napi munka: mi változik a Beanstalk-rutinhoz képest?

2.7Ellenőrizd magad