Web · Architektúra
Miért Firebase + Next.js + Vercel az alapértelmezett stackünk adminalkalmazásokhoz
Szinte minden mobiltermék mellé kell előbb-utóbb egy back-office is: egy adminfelület, ahol az ügyfél kezeli a felhasználókat, a tartalmakat és az adatokat. Ezekhez nálunk mindig ugyanaz a stack kerül elő – és az indoklás nagyrészt arról szól, mit nem kell megépítenünk.
Mivel állunk szemben
Az adminalkalmazásokat könnyű felismerni: néhány belső felhasználó, CRUD-képernyők a már meglévő adatok fölött, szerepköralapú hozzáférés – és nulla tolerancia arra, hogy az ügyfél pénze infrastruktúrára menjen el. Az admin nem maga a termék, hanem a terméket szolgálja ki. Ettől más a gazdasági logikája is: minden óra, ami az adminnál szerverekre, deploy-pipeline-okra vagy API-réteg építésére megy el, az egy óra, ami nem magára a termékre jut.
A mobilappjaink jellemzően eleve Firebase-en futnak: autentikáció, Firestore, fájltárolás, push-értesítések. Ez a már meglévő alap határozza meg leginkább a stackválasztást.
Firebase: a backend, ami már megvan
Ha a mobilapp adatai a Firestore-ban vannak, a felhasználói pedig a Firebase Authban, akkor az adminalkalmazás ingyen kap egy kész backendet. Nem kell REST API-réteget tervezni, megépíteni, dokumentálni és verziózni: az admin ugyanazokat a Firestore-kollekciókat olvassa és írja, ugyanazokon a security rule-okon keresztül.
A szerepköralapú hozzáférés ott dől el, ahol dőlnie kell: a Firebase Auth-felhasználókon custom claim jelöli, ki admin, a security rule-ok pedig szerveroldalon kényszerítik ki. Az adminfelület nem tud magának jogot osztani – a szabályok az egyetlen hiteles forrás, a mobilappnak és a dashboardnak egyaránt. Ami pedig nem futhat kliensen – tömeges műveletek, adatmigráció, értesítések kiküldése –, arra ott a Cloud Functions: szerveroldali logika anélkül, hogy szervert kellene üzemeltetnünk.
Next.js: CRUD-képernyők gyorsan
A Next.js az App Routerrel kifejezetten hatékony, ha dashboardot kell építeni. Az adatigényes lista- és részletnézeteket szerverkomponensek renderelik, így nem kell minden táblázathoz kliensoldali bundle-t küldeni; az interaktív részeket – űrlapokat, szűrőket, dialógusokat – klienskomponensek kezelik. A fájlalapú routing magától értetődően követi egy adminfelület szekcióit, a React-ökoszisztéma pedig érett táblázat-, űrlap- és diagramkomponenseket ad, így a képernyőket összerakjuk, nem pedig feltaláljuk.
Ráadásul ugyanaz a tudás kell hozzá: a webes termékeink – például a HajnalSugár platform – szintén Reacten és Next.js-en futnak, így az adminalkalmazások ugyanabban a világban élnek, mint minden más, amit webre szállítunk.
Vercel: a deploy nem téma többé
A Vercel zárja a kört: a deploy egyszerűen lekerül a napirendről. Minden push buildel, minden pull request kap egy preview URL-t, amit az ügyfél megnézhet, mielőtt bármi élesbe kerülne, a merge pedig maga a deploy. Nincs patchelendő szerver, nincs pipeline, amit pesztrálni kell, és egy tucatnyi felhasználót kiszolgáló belső eszköz hostingszámlája gyakorlatilag nulla.
A preview deployokat ügyfélmunkában külön érdemes kiemelni: az „itt a link a tegnap kért módosításhoz” olyan review-folyamat, amelyben egy nem technikai ügyfél is ténylegesen részt tud venni.
Amikor nem ez a stack a jó válasz
Az alapértelmezésnek is megvannak a határai. A Firestore dokumentumalapú adatbázis: ha az admin valódi feladata a komoly relációs riporting – entitásokon átívelő joinok, több millió soros aggregációk, a pénzügy havi exportjai –, akkor a relációs adatbázis a helyes választás, és ezt ki is mondjuk. Ugyanígy: ha egy szervezet már üzemelteti a saját backend-platformját, az admin annak mellé kerüljön, ne egy párhuzamos stackre.
Az alapértelmezés értéke nem az, hogy mindig ez nyer, hanem hogy az esetek 80%-ában – ahol egyébként is passzol – a döntés már meg van hozva, és a beszélgetés arról szólhat, mire kell valójában az ügyfélnek a dashboard.
Tanulságok
- ✓Ha a mobilapp már Firebase-en fut, az admin dashboard készen kapja a teljes backendet – nincs API-réteg, amit építeni vagy karbantartani kellene.
- ✓Az adminszerepköröket Firebase Auth custom claimekkel és security rule-okkal, szerveroldalon kényszerítsd ki – soha ne a felületen.
- ✓Az adatigényes CRUD-képernyőkhöz Next.js szerverkomponensek valók; a klienskomponensek maradjanak az interaktív részeknél.
- ✓A Vercel preview deployjaival az ügyfél-review egyetlen linkre kattintás – nem technikai érintetteknél ez aranyat ér.
- ✓Ismerd a határt: a komoly relációs riportinghoz relációs adatbázis kell, nem Firestore-akrobatika.
Olyan terméken dolgozol, ahol ez számít?
Minden projektünkben így dolgozunk, legyen szó mobilról, webről vagy AI-ról. Ha olyan csapatot keresel, amelyik így gondolkodik a termékedről, beszéljünk.
Kérj ingyenes becslést