Miért Nuxt? És miért pont Cloudflare-en

1.1Mit építesz ma — és hol fáj

A jelenlegi felállás nagyjából így néz ki: egy Vue SPA, amit Vite épít statikus fájlokká, kikerül egy CDN mögé, és böngészőből hívja az Express API-t, ami külön fut. Ez működő architektúra, sok nagy termék így üzemel. Nem az a kérdés, hogy rossz-e, hanem hogy hol fizetsz érte.

Négy visszatérő költség van benne:

• Két rendszer, két deploy, két konfiguráció. Külön build a frontendnek és a backendnek, külön környezeti változók, külön logolás, CORS a kettő között, és az örök kérdés, hogy melyik verzió melyikkel kompatibilis. A típusaid a határon elvesznek: az API válaszát a frontenden újra leírod (vagy nem, és akkor any).
• A böngésző kap egy üres HTML-t. Az első kérésre egy váz érkezik, aztán letöltődik a JS, lefut, és csak ezután indul el az első API-hívás. A felhasználó addig spinnert néz. Ez a mobilhálózaton nem 50 ms, hanem másodpercek.
• SEO és megosztás. Egy publikus projektoldal, egy megosztott link, egy marketing-oldal — mindnek szüksége van szerveroldali <title>-re és OG-tagre. SPA-ban ez vagy prerender-szolgáltatás, vagy külön statikus oldalak, vagy sehogy.
• Routing kézzel. Route-tábla, lazy import, guardok, layout-logika — mind kód, amit te tartasz karban, és ami minden új oldalnál módosul.

A Nuxt mind a négyre válaszol. Nézzük meg, hogyan — és utána azt, hogy mit kérdez cserébe.

1.2Az öt dolog, amit a Nuxt hozzáad

① Szerveroldali renderelés — és a hydration

A Nuxt alapból universal rendering módban fut: az első kérésre a szerveren lefuttatja a Vue-komponenseidet, és kész HTML-t küld. A böngésző ezt azonnal megjeleníti, majd letölti a JS-t, és „ráhidratálja” ugyanazt a komponensfát — innentől minden interakció ugyanúgy kliensoldali, mint eddig.

② Fájl-alapú routing

A route-tábla eltűnik. A könyvtárszerkezet a route-tábla:

app/pages/
  index.vue                     →  /
  login.vue                     →  /login
  projects/index.vue            →  /projects
  projects/[id].vue             →  /projects/:id
  projects/[id]/settings.vue    →  /projects/:id/settings
  [...slug].vue                 →  minden más (404 vagy CMS-oldal)

Ehhez jönnek a layoutok (app/layouts/) és a route middleware-ek (app/middleware/), amiket oldalanként rendelsz hozzá. Nincs többé „elfelejtettem regisztrálni a route-ot” hiba, viszont cserébe a fájlnevek konvenciója lesz a szabályrendszer, amit ismerned kell. A 4. modul ezt vezeti végig.

③ Adatlekérés, ami már a szerveren lefut

Ez a legnagyobb napi különbség. Ma valószínűleg így néz ki egy oldalad:

<script setup>
const route   = useRoute()
const project = ref(null)
const loading = ref(true)
const error   = ref(null)

onMounted(async () => {
  try {
    const res = await fetch(`/api/projects/${route.params.id}`)
    if (!res.ok) throw new Error(res.statusText)
    project.value = await res.json()
  } catch (e) { error.value = e }
  finally { loading.value = false }
})
</script>

<script setup lang="ts">
const route = useRoute()

// lefut a szerveren az SSR alatt, az eredmény a HTML-lel érkezik
const { data: project, status, error } = await useFetch(
  () => `/api/projects/${route.params.id}`
)

// és a meta is szerveroldalon dől el — ez az, ami SPA-ban nem megy
useSeoMeta({
  title:       () => project.value?.name ?? 'Projekt',
  description: () => project.value?.summary,
})
</script>

Nem csak rövidebb. A lényeg, hogy a lekérés a szerveren megtörténik, mielőtt a HTML elmegy — így nincs villanó spinner, a robot látja a tartalmat, és a <title> a valódi projektnév. Az 5. modul erről szól, mert van benne bőven csapda is (például hogy mi utazik ki a HTML-be a lekérés eredményéből).

④ Egy szerver a kettő helyett — Nitro

A Nuxt saját szerver-rétege a Nitro. Ugyanabban a projektben, ugyanazokkal a típusokkal írod az API-t:

// routes/projects.js
router.get('/:id', requireAuth, async (req, res, next) => {
  try {
    const project = await db.project.findFirst({
      where: { id: req.params.id, tenantId: req.session.tenantId },
    })
    if (!project) return res.status(404).json({ error: 'Not found' })
    res.json(project)
  } catch (err) { next(err) }
})

// server/api/projects/[id].get.ts   ← a fájlnév adja az útvonalat ÉS a metódust
export default defineEventHandler(async (event) => {
  const { tenantId } = await requireSession(event)   // server/utils/, auto-import
  const id = getRouterParam(event, 'id')

  const project = await useDb(event).query.projects.findFirst({
    where: and(eq(projects.id, id), eq(projects.tenantId, tenantId)),
  })

  if (!project) throw createError({ statusCode: 404, statusMessage: 'Nincs ilyen projekt' })
  return project   // a szerializálás automatikus
})

Amit itt nyersz: a válasz típusa végigmegy a useFetch-ig, tehát a komponensben tudja a TypeScript, mi van a project-ben. Nincs kétszer leírt típus, nincs CORS, nincs külön deploy. A 8. modul a teljes Express→h3 megfeleltetést hozza.

⑤ Konvenciók és a modulrendszer

Auto-import (komponensek, composable-ok, server/utils), kész felállás a TypeScripthez, és egy modul-ökoszisztéma, ahol egy sor a nuxt.config.ts-ben elintézi a képoptimalizálást, az i18n-t vagy a fontkezelést. Ez a rész az, ami a legjobban gyorsít — és amiért cserébe a legtöbbet fizetsz kontrollban. Lásd rögtön a következő szakaszt.

1.3Mit veszítesz — az őszinte lista

Ezt a részt komolyan vedd, mert a Nuxt-marketing nem fogja elmondani.

• Keretrendszer-kötöttséget vállalsz, verziózással együtt. A Nuxt major verziói jönnek, és a támogatás lejár. Konkrétan: a Nuxt 3 támogatása 2026. július 31-én véget ért — pár napja. Aki nem lépett 4-re, biztonsági javítás nélkül maradt. A Nuxt 5 (Nitro v3-mal) a láthatáron van. Ez nem elméleti kockázat, hanem egy visszatérő, tervezendő munkatétel: nagyjából 2-3 évente egy migráció.
• Mágia. Az auto-import és az implicit routing kényelmes, amíg működik. Amikor nem, az első kérdés az lesz, hogy „ezt most ki csinálta?” — és a válasz gyakran a .nuxt/ könyvtárban generált kódban van. Egy ismeretlen useValami() hívásnál nem látod az importból, honnan jön.
• Nehezebb hibakeresés, mert a kód két helyen fut. Ugyanaz a komponens lefut a szerveren és a kliensen. Ha a kettő eredménye eltér, hydration mismatch lesz belőle — ez a leggyakoribb „miért csinálja ezt?” pillanat Nuxtban. Az SPA-ban ilyen hibaosztály egyszerűen nem létezik.
• Az ökoszisztémára támaszkodsz. A Nuxt-modulok minősége szórt. Egy elhagyott modul a te problémád lesz a következő major verziónál — és pont akkor derül ki, amikor frissítenél.
• Lassabb build, összetettebb pipeline. Egy vite build helyett kliens- és szerverbuild, prerender-fázis, Nitro-csomagolás. A CI-d lassabb lesz, a hibaüzenetek távolabbiak.
• A „Nuxt-módra” kényszer. Ha valamit nem úgy akarsz csinálni, ahogy a Nuxt gondolja, az többe kerül, mint keretrendszer nélkül. A konvenció akkor ajándék, ha egyetértesz vele.

1.4Mikor ne Nuxt?

1.5Nuxt a mezőnyben

Röviden és elfogultság nélkül, kifejezetten a „Cloudflare-en fogok hostolni” szempontból:

Nálad a Vue-tudás adott, tehát a valódi kérdés nem a Nuxt vs. Next, hanem a Nuxt vs. a mostani Vue SPA + Express. Erre válaszol az 1.2 és az 1.3.

1.6Miért illik pont a Cloudflare-hez

Ez az a rész, ami miatt ez a tananyag nem általános Nuxt-kurzus. Négy konkrét ok:

1. A Workers nem „port”, hanem első osztályú cél. A Nitro preset-rendszere miatt a Cloudflare ugyanolyan build-célpont, mint bármelyik másik. A Next.js-nél ehhez egy külön adapter-projekt (OpenNext) kell, ami definíció szerint mindig egy lépéssel a keretrendszer mögött jár.
2. Egyetlen deploy-egység. Az SSR-kód és a statikus assetek egy Workerben mennek ki, a CDN pedig nem egy külön réteg, hanem maga a hálózat. A mostani S3 + CloudFront + ALB + Beanstalk négyesből egy darab wrangler deploy lesz.
3. A server routes közvetlenül lát bindingokat. A server/api/-ban a D1, R2, KV, Queues nem SDK-n és API-kulcson keresztül érhető el, hanem közvetlen referenciaként (event.context.cloudflare.env). Nincs hálózati ugrás, nincs kulcskezelés.
4. Az SSR tényleg a felhasználó közelében fut. Régió-alapú hostingnál az ausztrál felhasználód kérése átmegy a fél világon, mielőtt egy pixel megjelenne. Itt a renderelés az edge-en történik — és pont az SSR az, ami ebből a legtöbbet profitál.

1.7Mit jelent ez konkrétan a te SaaS-odra

Multitenant SaaS-nál három dolog számít a fentiekből igazán:

• A publikus felület tényleg profitál az SSR-ből. Marketing-oldalak, megosztott linkek, publikus projekt- vagy dokumentumnézetek, tenant-onkénti egyedi domainek — ezek mind olyan tartalmak, ahol a szerveroldali meta és a gyors első festés valódi üzleti érték. Az alkalmazás belső része ebből keveset lát; ez nem baj, csak tudni kell.
• A tenant-kontextus egyetlen helyre kerül. Ma valószínűleg a frontend is tudja, melyik tenantban vagy, és az Express is. Nuxtban a szerver-middleware egy helyen oldja fel (domain, subdomain vagy útvonal alapján), és onnantól mind az SSR, mind a server routes ugyanazt látja. A 4. és 10. modul erről szól.
• A layerek white-label-hez valók. Ha valaha lesz tenant-specifikus arculat vagy funkció, a Nuxt layers pont erre készült — külön kódbázis nélkül. Ez az a képesség, ami a Vue SPA + Express felállásban házilag megírandó lenne (14. modul).

1.8Ellenőrizd magad