Migrációs recept: Vue SPA + Express → Nuxt a Cloudflare-en

21.1A vasszabály: nincs big-bang

A „félreteszünk hat hetet, újraírjuk, aztán átkapcsolunk” terv azért csábító, mert egyszerűnek hangzik. A gyakorlatban két dolog történik vele: a hat hétből öt hónap lesz, és mivel közben a régi rendszer is fejlődik, folyamatosan utol kell érned egy mozgó célt. Az átkapcsolás napja pedig egyetlen, hatalmas, visszavonhatatlan kockázat.

A működő alternatíva a fojtófüge-minta: az új rendszer körbenövi a régit, útvonalanként átveszi a funkciókat, és amikor az utolsó is átkerült, a régi egyszerűen kikapcsolható. Minden lépés kicsi, mérhető, és önmagában visszafordítható.

21.2A leltár: hat kérdés indulás előtt

Mielőtt egy sort írnál, ezekre kell írásos válasz. Nem azért, mert szeretjük a dokumentációt, hanem mert mindegyik megváltoztathatja a migráció alakját.

21.3A fojtófüge Cloudflare-en: a Worker mint kapu

A proxyzás egyetlen h3-segédfüggvény (8. modul), egy szerver-middleware-ben:

// server/middleware/99-legacy-proxy.ts — a NÉV SZÁMÍT: fusson utolsóként
const MAR_MIENK = [
  '/sugo',
  '/kapcsolat',
  '/api/termekek',
  // ide kerül minden átvett útvonal — ez a migráció mérőszáma
]

export default defineEventHandler(async (event) => {
  const url = getRequestURL(event)

  // már a miénk → engedd tovább a Nuxtnak (a middleware nem tér vissza semmivel)
  if (MAR_MIENK.some(p => url.pathname === p || url.pathname.startsWith(p + '/'))) return

  // minden más → a régi rendszer
  const { legacyOrigin } = useRuntimeConfig(event)
  return proxyRequest(event, legacyOrigin + url.pathname + url.search, {
    headers: {
      'X-Forwarded-Host': url.host,
      'X-Forwarded-Proto': 'https',
    },
  })
})

21.4Öt fázis, mindegyik külön visszavonható

21.5A Vue SPA átemelése

Jó hír, hogy a komponensek nagy része szó szerint átmásolható. A rossz hír, hogy pont a keretrendszer-szintű dolgok nem — és azok vannak mindenütt.

21.6Az Express-réteg átköltöztetése

A 8. modulban végigmentünk a leképezésen: req.params → getRouterParam, req.query → getQuery, res.json → egyszerű return, és így tovább. A migráció szempontjából három dolog fontos ezen felül:

A sorrend átértelmeződik

Expressben a middleware-ek regisztrálási sorrendben futnak, és a next() hívása dönt. A Nitro szerver-middleware-jei fájlnév szerint ábécésorrendben futnak, és a „továbbengedés” azt jelenti, hogy nem térsz vissza semmivel. Ezért kezdődik a proxy fájlneve 99--cel: hogy garantáltan utolsóként fusson, miután az auth- és tenant-middleware-ek már elvégezték a dolgukat.

Amit nem tudsz átvinni

Az API-szerződés megőrzése

21.7A session-híd — a legnehezebb rész

A párhuzamos üzem egyetlen igazán nehéz problémája ez: a felhasználó bejelentkezett a régi rendszeren, és most egy új útvonalra navigál. Az új rendszernek fel kell ismernie. Fordítva ugyanígy.

Három megközelítés van, egyre növekvő tisztasággal:

Az ①-es a helyes választás, ha a session-tár adatbázis (Postgres, Redis). A minta, ami ezt elegánssá teszi, a felolvasáskori átemelés: az első alkalommal, amikor a felhasználó egy migrált útvonalra téved, a régi session alapján kiállítunk neki egy újat. Onnantól a gyors, kriptográfiai úton ellenőrzött süti-session él, adatbázis-hívás nélkül.

// server/utils/session-hid.ts
export async function regiSessionFeloldas(event: H3Event) {
  const nyers = getCookie(event, 'connect.sid')
  if (!nyers) return null

  const sid = sidKibont(nyers)               // s:<id>.<aláírás> → id
  if (!alairasErvenyes(nyers)) return null   // a régi titokkal ellenőrizve

  const db = useDb(event)
  const [sor] = await db.query(
    'SELECT sess FROM session WHERE sid = $1 AND expire > now()', [sid],
  )
  return sor?.sess?.passport?.user ?? null
}

// server/middleware/10-auth.ts — fut a proxy ELŐTT (10 < 99)
export default defineEventHandler(async (event) => {
  const munkamenet = await getUserSession(event)
  if (munkamenet?.user) return                // már az új rendszerben van

  const regiUser = await regiSessionFeloldas(event)
  if (!regiUser) return                        // nincs bejelentkezve — rendben

  // ÁTEMELÉS: mostantól az új session él, DB-hívás nélkül
  await setUserSession(event, {
    user: { id: regiUser.id, email: regiUser.email, tenantId: regiUser.tenant_id },
    atemeltRegiSessionbol: true,
  })
})

21.8Az adatréteg: mit viszel, mit hagysz

A leggyakoribb migrációs túlvállalás az, hogy az adatbázist is lecserélik közben. Ne. A 4. és 11. modul döntési fája szerint:

21.9Amit ne migrálj

Ez a szakasz felszabadító: a migráció sikere nem azon múlik, hogy minden átkerül. Egy jól eltalált végállapotban marad egy kis Node-szolgáltatás, ami azt csinálja, amire Workers-en nincs jó válasz — és ez nem kudarc, hanem tervezés.

• Hosszú, CPU-igényes feldolgozás — PDF-generálás nagy dokumentumokból, videó, képtömeg, nagy exportok.
• Natív bináris köré épült funkció — képmanipuláció saját pipeline-nal, tudományos könyvtárak.
• Ritkán hívott, bonyolult végpont, aminek az átírása napokba kerülne és havonta ötször fut.
• Külső rendszerrel tartott hosszú kapcsolat — perzisztens SFTP, üzenetsor-fogyasztó.

21.10Ütemterv és visszavonulás

Egy közepes méretű alkalmazásra reális minta. A hetek számai nem jóslatok, hanem arányok: a lényeg, hogy a felmérés és az első útvonal együtt az idő harmadát viszi, és ez nem pazarlás.

Három dolog, ami a visszavonulást működőképessé teszi

1. A MAR_MIENK lista legyen konfiguráció, ne kód. Ha runtimeConfig-ból vagy egy KV-kulcsból jön, egy útvonal visszaadása a régi rendszernek deploy nélkül megtehető — másodpercek alatt, éjjel is.
2. A régi rendszer maradjon futóképes a teljes migráció alatt, és még utána is néhány hétig. A leállítás önálló, tudatos lépés legyen, nem a migráció mellékterméke.
3. Minden fázisnak legyen mérőszáma. Nem „kész-e”, hanem: hány útvonal a miénk, mekkora a proxyzott forgalom aránya, hány felhasználó jött még régi session-nel. Ezekből látszik a haladás — és az is, ha valami megállt.

21.11Ellenőrizd magad