A nagy döntés: full-stack Nuxt vagy külön API?

9.1A két út — és a harmadik, ami a valóság

9.2A hét szempont

9.3A latency-paradoxon — ez dönt Cloudflare-en

Ez a modul legfontosabb szakasza, és pont az a szempont, ami az általános „Nuxt full-stack vagy nem” vitákban nem szokott szerepelni, mert csak edge-hostingnál él.

Az SSR értelme az, hogy a szerver gyorsan össze tudja rakni a HTML-t. Ehhez adatot kér le. Ha a Worker az edge-en fut — mondjuk a felhasználóhoz közel, Budapesten —, de az API az AWS eu-central-1-ben, akkor minden egyes SSR-lekérés kimegy Frankfurtba és vissza.

Négy válasz létezik erre, és mind a négy legitim:

9.4Hol húzd meg a határt (a hibrid)

A legtöbb csapat ide köt ki. Nem kompromisszum, hanem tudatos felosztás: ami a felhasználóhoz közel értékes, az menjen a Nitróba; ami nehéz vagy nem edge-barát, maradjon kint.

9.5Ha BFF-et választasz: a helyes minta

// server/utils/upstream.ts — egy helyen kezelt kimenő hívás
export function upstream(event: H3Event) {
  const cfg = useRuntimeConfig(event)

  return $fetch.create({
    baseURL: cfg.apiBaseUrl,
    timeout: 5000,

    onRequest({ options }) {
      // ✗ SOHA ne told tovább a felhasználó cookie-ját
      // ✓ a szerver a saját, rövid életű szolgáltatás-tokenjével hív
      options.headers.set('authorization', `Bearer ${serviceToken(cfg)}`)
      options.headers.set('x-tenant-id',   event.context.tenant.id)
      options.headers.set('x-request-id',  event.context.requestId)
    },

    onResponseError({ response }) {
      // a belső hibaformátumot fordítsuk a sajátunkra (5. modul)
      throw createError({
        statusCode:    response.status === 401 ? 403 : response.status,
        statusMessage: response._data?.message ?? 'Upstream hiba',
      })
    },
  })
}

// server/api/dashboard.get.ts — ÖSSZEVONÁS: 1 kérés a böngészőnek, párhuzamos upstream
export default defineEventHandler(async (event) => {
  await requireSession(event)
  const api = upstream(event)

  const [projects, usage, notices] = await Promise.all([
    api('/projects?limit=10'),
    api('/usage/current'),
    api('/notices'),
  ])

  // és itt formázzuk a DTO-t — a belső séma nem szivárog ki (5. modul)
  return { projects: projects.map(toProjectDto), usage: toUsageDto(usage), notices }
})

9.6Ha full-stack Nuxtot választasz: mire figyelj

• A service-réteg ne ismerje az event-et (8. modul). Ez tartja nyitva az ajtót visszafelé is.
• A HTTP nem az egyetlen belépési pont. Cron és sorbaállított munka is hívja majd ugyanazt a logikát — a Cloudflare-anyag 7. modulja a Queues/Workflows/Cron hármast tárgyalja, és ezek ugyanabban a Workerben élnek.
• Verziózz, ha lesz külső fogyasztó. Ha ma csak a saját frontended hívja az API-t, holnap viszont egy mobilapp is, akkor jobb már most /api/v1/-ként indulni, mint később törni.
• Tartsd szemmel a bundle-t és a CPU-időt. Ahogy nő a szerverkód, nő a Worker mérete is — a 15. modul erről szól.
• A nehéz munkát tedd külön. Ami nem fér a CPU-korlátba, az Queue-consumerbe, Workflow-ba vagy Containerbe való, nem a kérés-útvonalba.

9.7Ha B-ből A felé mész: a sorrend

A biztonságos út a strangler-minta: nem cserélsz, hanem körbenősz.

1. 1. fázis — Nuxt frontend + vékony BFF. Az Express API változatlan. Csak a session/auth kerül a Nitróba (ez amúgy is oda való, mert cookie-kezelés), plusz az összevonó végpontok. Kockázat: alacsony. Ez már önmagában érték: gyorsabb oldal, kevesebb kérés.
2. 2. fázis — minden új végpont a Nitróban készül. Nem migrálsz, csak nem növeled tovább a régit. Itt derül ki, mennyire kényelmes a Nitro a csapatnak — élesben, valós funkción.
3. 3. fázis — meglévő végpontok átköltöztetése domain-enként. Nem fájlonként: egy összetartozó terület (mondjuk „projektek”) egyszerre, a service-logikájával együtt. Útvonalanként lehet átkapcsolni, és vissza is.
4. 4. fázis — az Express kikapcsolása. Csak akkor, ha tényleg üres. Nem cél, hanem lehetséges végállapot.

9.8Döntési checklist

Válaszolj őszintén; a jelölés mutatja, merre húz a válasz.

9.9Ellenőrizd magad