Full-stack és frontend: Nuxt a Workers-en

3.1A nagy egyszerűsödés: négy rétegből egy

Idézzük fel, mi kell ma egy éles Nuxt apphoz AWS-en: a statikus buildet S3-ba teszed, elé CloudFront distributiont konfigurálsz (origin-ök, behavior-ök, invalidation deploykor), az SSR-hez Node-szerver fut Beanstalkon ALB mögött, és a kettő határvonalát a CDN routing-szabályaiban kézzel húzod meg. Négy szolgáltatás, négyféle konfiguráció, és a „melyik réteg cache-el most rosszul?" típusú hibakeresés.

A Workers-modellben ugyanez egyetlen egység: a Worker deploy tartalmazza az SSR-kódot és a statikus asseteket (Static Assets), a CDN-viselkedés pedig a platform beépített tulajdonsága. A kérés-útvonal döntési logikája így néz ki:

Két szabályt érdemes megjegyezni. Egy: asset először — ha az URL statikus fájlra illeszkedik, a Worker el sem indul (nem is fizetsz érte: az asset-kérések ingyenesek és korlátlanok). Kettő: ha a Worker kap egy kérést, bármikor vissza is dobhatja az asseteknek az env.ASSETS.fetch(request) hívással.

3.2Pages vs. Workers — tegyük rendbe egyszer s mindenkorra

Keresgélés közben két párhuzamos világot fogsz látni a docsban és a tutorialokban: Cloudflare Pages (a „Netlify-szerű" frontend-hosting, saját Git-integrációval, *.pages.dev domainnel) és Workers Static Assets. A történet egyszerű: a Pages volt az első full-stack válasz, de a platform két lábon állt — a Pages Functions valójában Workers volt, korlátozott képességekkel. 2024–25-ben a Cloudflare összevonta a két világot: a Workers megkapta a statikus asset-kiszolgálást, és minden új képesség oda érkezik (gradual deployments, teljes bindings-választék, observability, Durable Objects…). A Pages működik és támogatott, de funkcionálisan lezárt — új projektet Workersre építs, meglévő Pages-projekthez pedig van hivatalos migrációs útmutató.

3.3Nuxt a Workers-en: hogyan áll össze

A jó hír: a Nuxt szerveroldali motorja, a Nitro, natívan ismeri a Cloudflare-t. A cloudflare_module preset a buildkor két részre bontja az appot: a kliens-bundle és a statikus fájlok mennek a Static Assets-be, a szerveroldal (SSR + a server/ mappád API route-jai) pedig egyetlen Worker-modullá fordul. Vagyis a Nuxt-kódod nem változik — a route-ok, a defineEventHandler-es API-k, a middleware-ek ugyanazok maradnak; a build-cél változik.

export default defineNuxtConfig({
  nitro: {
    preset: "cloudflare_module",   // Worker-modul + Static Assets build
  },
  modules: ["nitro-cloudflare-dev"], // bindings lokális dev alatt is
});

{
  "name": "my-nuxt-app",
  "main": "./.output/server/index.mjs",   // a Nitro által generált Worker
  "compatibility_date": "2026-08-02",
  "compatibility_flags": ["nodejs_compat"],
  "assets": {
    "directory": "./.output/public",      // kliens-bundle, képek, css
    "binding": "ASSETS"
  },
  // és ide jönnek majd a bindings: hyperdrive, r2_buckets, queues…
}

Új projektnél az egészet a generátor összerakja (npm create cloudflare@latest -- my-app --framework=nuxt); meglévő projektnél a fenti két fájl a lényeg. A deploy innen már ismerős: npm run build && wrangler deploy.

Bindings elérése a Nuxt server route-okban

A Cloudflare-világ a defineEventHandler kontextusán át érhető el — itt ér össze az 1. modul bindings-modellje a megszokott Nuxt-kódoddal:

export default defineEventHandler(async (event) => {
  const { env, context } = event.context.cloudflare;

  // R2-be írás — mintha lokális objektum lenne (6. modul)
  await env.UPLOADS.put(`u/${crypto.randomUUID()}`, event.node.req);

  // háttérmunka a válasz után (2. modul!)
  context.waitUntil(trackUpload(env));

  return { ok: true };
});

Típusokhoz futtasd a wrangler types-t, és deklaráld az env-et a H3EventContext-en — így az env.UPLOADS teljesen típusos. Lokális fejlesztésnél a nitro-cloudflare-dev modul a Wrangler-konfigod alapján szimulálja a bindingokat a megszokott nuxt dev alatt — tehát marad a HMR-es, gyors Nuxt-élmény, miközben R2/KV/D1 hívásaid működnek.

3.4Cache és CDN: amit a CloudFrontnál konfiguráltál, itt alapértelmezés

A statikus assetek cache-elése automatikus: az első kérés után az asset a legközelebbi PoP-ban cache-elődik, a tiered caching pedig gondoskodik róla, hogy távoli PoP-ok is egymástól, ne a tárolótól kérjék. Amit a CloudFrontnál kézzel csináltál, itt így alakul:

export default defineNuxtConfig({
  routeRules: {
    "/":          { swr: 600 },       // stale-while-revalidate 10 percig
    "/blog/**":   { isr: 3600 },      // generálás után 1 óráig cache
    "/admin/**":  { cache: false },   // soha ne cache-eld
  },
});

3.5Ellenőrizd magad