A mi stack-ünk — Angular, Firebase, Cloud Functions
Minden szoftvercégnek van egy bevált technológia-csomagja, amit a napi munkájában használ. A miénk az Angular + Firebase + Cloud Functions/NestJS. Ez nem véletlen választás, és nem is divat-követés. Évek tapasztalata, sok elvégzett projekt vezetett el oda, hogy pontosan tudjuk, mit miért használunk.
A kevesebb néha több
Kis- és középvállalkozásokra szabva
Az ígéretünk
- Modern, hosszú életű eszközök — nem múló trend. Mind a négy fő elem (Angular, Firebase, NestJS, Google Cloud) világszerte használt szabvány.
- Átlátható havi költségek — a használat-alapú díjazás miatt a kis projektek havi pár ezer forintot „esznek”. Egy klasszikus megoldás minimum havi 15–30 ezer.
- Bővíthetőség újraépítés nélkül — ha a vállalkozásod nő, a szoftver együtt nő veled. Nem kell mindent újraírni 2 év múlva.
- Cserélhető fejlesztők — minden elem nyilvános szabvány. Ha váltani kell, nem leszel hozzánk kötve.
A felület — amit a kollégáid és az ügyfeleid látnak — Angular-ral épül. Ez a Google által karbantartott keretrendszer, amit nagy cégek (banki, biztosítói, egészségügyi) is használnak. Megbízható, stabil, és kifejezetten alkalmas hosszú életű üzleti alkalmazásokhoz.
Miért Angular, és nem mondjuk React?
A teljes csomag: az Angular-ban benne van az útvonalkezelő, az űrlapkezelő, a HTTP-kliens, a tesztelési keretrendszer, a fordító. Egy React-projektnél ezeket külön kell összeválogatni — és minden ilyen választás egy újabb kockázat. Velünk a vállalkozó megspórolja ezeket a döntéseket.
Konkrét előnyök egy KKV-szoftvernek
- Hosszú életű projektekhez ideális — az Angular minden 6 hónapban kiad új változatot, automatikus átállást segítő eszközökkel (
ng update). Egy 5 éves projektnél óriási segítség. - Erős TypeScript-támogatás — sokkal kevesebb futásidejű hiba, mert a fordító már a kódoláskor jelzi a problémákat.
- Beépített teszt-szemlélet — minden generált fájl mellé tesztkeret jön. A tesztelhetőség nem utógondolat.
- Erős kész komponens-csomagok — Angular Material, PrimeNG, és más jól dokumentált csomagok gyorsítják a fejlesztést.
Egy ugyanazon Angular-projekt háromféleképpen tud „futni”: SPA, SSR vagy SSG. Mindhárom más célra való. Ezt projekt-szinten választjuk meg, néha keverve is használjuk őket.
SPA — Single Page Application
A klasszikus modern weboldal: a böngésző egyszer betölti az alkalmazást, és onnan minden navigáció pillanatnyi — nem kell újratölteni az oldalt. Olyan, mint egy asztali alkalmazás, csak böngészőben.
SSR — Server-Side Rendering
A szerver előre legyártja az oldal HTML-jét, a böngésző megkapja és megjeleníti — és csak utána tölti be a JavaScript-et. Ezzel a kezdeti betöltés gyorsabb, és a Google keresőrobotjai is jól indexelik az oldalt.
SSG — Static Site Generation
Az oldalakat előre, fordítás-időben legyártjuk — és kész HTML-fájlokat szolgálunk ki. Nincs szükség szerverre, nincs adatbázis-lekérdezés. A leggyorsabb és legolcsóbb megoldás.
A kombinált megközelítés
A felület mögött áll a háttér — ahol az adatok tárolódnak, a logika fut, és ahol a fizetős szolgáltatások bekötése történik. Erre a célra a Google Firebase felületét használjuk, ami egy KKV-méretű szoftvernek a legjobb mérleget adja: erős, megbízható, és a használat-alapú díjazás miatt a kis projekteknek szinte ingyenes.
Mi a Firebase?
A Firebase a Google felhő-szolgáltatásának egy KKV-barát átfogó csomagja. Több szolgáltatást egyesít egy felületen: adatbázis (Firestore, SQL Connect), fájltárolás (Storage), bejelentkezés (Authentication), szerver-funkciók (Cloud Functions), webhosting. Mind egy felügyeleti felületen.
Miért Firebase, és nem saját szerver?
- Nincs szerver-üzemeltetés — a Google gondoskodik a gépekről, a biztonsági frissítésekről, a tűzfalakról. Nem kapsz hajnali háromkor SMS-t, hogy „leállt a szerver”.
- Magától nő veled — ha holnap 10× annyi felhasználód lesz, a Firebase elviszi. Egy saját szerver ezen elbukik.
- Beépített biztonsági mentés — automatikus, naponta, többszörözve.
- Csak a használat után fizetsz — egy ritkán használt felügyeleti felület havi költsége akár pár száz forint. Egy saját szerver minimum havi 10–15 ezer.
- Élő frissítés — a Firestore valós időben szinkronizál, ami sok funkciónál szinte ingyen ad „élő” érzést.
A Firestore a Firebase NoSQL adatbázisa — a gyors fejlesztés, az élő szinkronizáció, és a használat-alapú díjazás kulcsa. Az esetek 70%-ában ez a fő adatbázis, amit egy KKV-projektben használunk.
Mi az a NoSQL — és miért jó?
A klasszikus adatbázisok (PostgreSQL, MySQL) szerkezetűek: minden ügyfélnek ugyanaz a mezőszáma, minden megrendelésnek pontosan ugyanazok a tulajdonságai. A NoSQL — mint a Firestore — rugalmasabb: dokumentumokban tárol, és minden dokumentum lehet kissé más felépítésű.
Ez azért jó, mert egy szoftver-fejlesztés során az adatok szerkezete sokat változik. Egy NoSQL adatbázisban új mezőt hozzáadni egy adathoz pár perc. Egy SQL-adatbázisnál ez gyakran komoly átalakítás, fél napos leállással.
A Firestore kiemelt előnye: élő frissítés
Mikor használjuk a Firestore-t?
- Belső felügyeleti felületek, ahol több kolléga dolgozik egy időben
- Élő naptárak, foglalási rendszerek
- Kimutató felületek élő mutatókkal
- Csomag-követés, megrendelés-állapotok
- Chat-szerű kommunikáció
- Általában: minden, ami gyorsan változó, többfelhasználós, és nem igényel bonyolult kapcsolatokat az adatok között
Nem mindenre jó a NoSQL. Vannak olyan szoftverek, ahol a klasszikus, táblázatos adatbázis-szerkezet jobb választás — különösen, ha sok kapcsolat van az adatok között, vagy ha bonyolult kimutatások kellenek. Erre való a Firebase SQL Connect szolgáltatása.
Mi a SQL Connect?
Mikor választjuk az SQL Connect-et a Firestore helyett?
- Bonyolult kapcsolatok az adatok között — pl. egy építőipari rendszerben: ügyfél → projekt → kivitelező → anyagok → számlák.
- Bonyolult kimutatások, statisztikák — havi forgalmi, ügyfél-szegmens elemzések. Az SQL-nek erre vannak erős eszközei.
- Pénzügyi vagy raktári mozgások — pl. két számla közötti pénzátutalás, ahol pontosan biztosnak kell lennie, hogy mindkét oldal megtörtént vagy egyik sem.
- Költözés más rendszerről — ha egy meglévő SQL-rendszerről jövünk át, sokszor egyszerűbb az SQL-formát megtartani.
A kombinált használat
A Firebase-csomag két másik fontos eleme: a Storage a fájlok kezelésére, és az Authentication a felhasználói belépésre. Mindkettő olyan funkció, amire szinte minden szoftverben szükség van, és amit klasszikusan komoly munkával kellene saját kézzel megépíteni.
Firebase Storage — fájlok tárolása
Egy felhőben élő fájltároló, ahova a felhasználók képet, dokumentumot, videót tölthetnek fel. Pl. egy építőipari rendszernél a helyszíni fotók, az ajánlatok PDF-ben, az aláírt szerződések.
Firebase Authentication — belépés
A felhasználói belépés kezelése: e-mail+jelszó, Google-fiók, Apple-fiók, telefonszám-alapú belépés, SMS-megerősítés. Mindezt kész állapotban kapod, a Google biztonsági szabványaival.
Nem minden logika egyszerű. Vannak feladatok, amik bonyolultabb szerver-oldali kódot igényelnek — pl. NAV-számla előállítása, e-mail-küldés, fizetés-feldolgozás, AI-modell lekérdezése. Erre a célra a Firebase Cloud Functions szolgáltatást használjuk, amiben NestJS-keretrendszerben írjuk a kódot.
Mi az a Cloud Functions?
Miért NestJS?
A Cloud Functions önmagában elég egyszerű — egy JavaScript-függvény, ami kérésre lefut. Ez egy nagyobb projekten kaotikussá válik. A NestJS egy keretrendszer, ami a Cloud Functions tetejére rendet ad: modulok, függőség-befecskendezés, jelölő szintaxis, beépített ellenőrzések. Olyan ez, mint az Angular a felület-oldalon — egy bevált rend, ami nagy projekteken is áttekinthető marad.
Konkrét NestJS-feladatok
- NAV-szabványos számla előállítása és bejelentése
- Számlázz.hu vagy Billingo bekötése
- E-mail-küldés (Mailgun, SendGrid, Brevo)
- SMS-küldés (Twilio, BulkSMS)
- Fizetés-feldolgozás (Stripe, Barion, K&H, OTP)
- Bonyolult adatfeldolgozás, ütemezett feladatok
- AI-szolgáltatások lekérdezése (OpenAI, Google Vertex AI)
- Külső szolgáltatások bekötése (Google Calendar, futárszolgálatok)
És Cloud Run?
A nagyobb, hosszabb futású feladatokhoz (pl. egy bonyolult AI-modell, képfeldolgozás, videó-átalakítás) a Cloud Run szolgáltatást használjuk — ez egy testvér-szolgáltatás, ami nem 60 másodperces függvényeket futtat, hanem akár hosszabb folyamatokat is. Ugyanúgy szerver nélkül működik, használat-alapú díjazással.
Angular ↔ Firestore — élő felület
NestJS ↔ Angular — egységes típus-rendszer
Firestore + SQL Connect — együtt a két világ
Felhő-natív, kezdettől fogva
Ha velünk dolgozol, nemcsak egy szoftvert kapsz — egy egész szemléletmódot is. Néhány konkrét ígéret, amit a választásunk lehetővé tesz, és amiket a napi munkánkban betartunk.
- Modern, stabil eszközök — az Angular és a Firebase nem múló divat. 8–10 éve léteznek, a Google folyamatosan fejleszti őket. A projekted 5–10 év múlva is karbantartható lesz.
- Átlátható havi költségek — a Firebase használat-alapú díjazása miatt egy kis projekt havi költsége akár pár ezer forint. Egy klasszikus szerver-megoldás minimum havi 15–30 ezer.
- Magától nő veled — ha holnap 10× annyi felhasználód lesz, nem kell semmit átépíteni. A Firebase és a Cloud Run magától együtt nő veled.
- Élő frissítés ott, ahol kell — a Firestore élő-frissítése sok funkciónál szinte ingyen-extra.
- Automatikus biztonsági mentés — a Google készíti és tárolja. Nem kell rá külön szerződni.
- Európai szabványos belépés — az Authentication ugyanaz a rendszer, amit a Google saját szolgáltatásai is használnak. GDPR-megfeleléssel.
- Egységes típus-rendszer — a háttér és a felület között nincs félreértés. Egy mező hozzáadása egy helyen történik.
- Cserélhető fejlesztők — minden elem, amit használunk, nyilvános szabvány. Ha valamiért váltani kell, a projekted nincs hozzánk kötve.
Nem akarjuk azt állítani, hogy ez mindenre jó. Vannak olyan projektek, amikre más megoldás megfelelőbb — fontos őszintén elmondani, mert egy KKV-vezető megérdemli az átlátható tájékoztatást.
Amikor nem javasoljuk a Firebase-t
- Ha az adatoknak Magyarországon kell maradniuk jogi okból — pl. bizonyos egészségügyi, banki, gyermekvédelmi szabályozások. Ekkor magyar vagy európai szolgáltatóra megyünk át.
- Nagyon nagy, állandó forgalom — havi sok millió kérés esetén egy saját szerverpark hosszú távon olcsóbb lehet. De ez a KKV-szektorban ritka.
- Különleges adatszerkezet — egyes ipari szoftverekhez (pl. CAD, képfeldolgozás, ipari mérőrendszerek) más adattároló jobban illik.
Amikor nem javasoljuk az Angular-t
- Egyszerű marketing-oldal — egy ötoldalas céges weboldalhoz nem kell Angular. Egy egyszerű HTML+CSS, vagy egy WordPress jobb választás.
- Egyszemélyes prototípus — gyors kísérletezésre egy egyszerűbb keretrendszer (Vue.js, Svelte) gyorsabban indul.
Ez a cikk egy bemutatkozás volt — a teljes munkánk áttekintése. A blogon a következő cikkekben minden elemet külön, részletesen is elmagyarázunk, mert úgy gondoljuk, hogy egy átlátható partnerség az alapja annak, hogy hosszú távon sikeres legyen a közös munka.
Részletes cikkek az egyes elemekről
- Angular áttekintés — a keretrendszer 2024–26-os megújulása, Signals, zoneless, önálló komponensek
- Firebase felület áttekintés — a teljes csomag bemutatása
- Firestore adatszervezés — hogyan tervezzünk adatszerkezetet
- Firebase SQL Connect — a Postgres-megoldás részletei
- Firebase Security Rules — adat-szintű biztonsági szabályok
- Firebase Hosting — a felhő-szolgáltatás
- Firebase Authentication — felhasználó-kezelés és belépés
- Firebase Cloud Functions — szerver nélküli háttér
- Cloud Run — hosszabb feladatok futtatása
- GraphQL bevezetés — a modern lekérdezési stílus
A választott eszközök nem önmagukért vannak. Azért vannak, hogy az ügyfél jó szoftvert kapjon — gyorsan, megbízhatóan, és hosszú távon. Mi azokat választottuk, amik ezt a legjobban szolgálják.