← Vissza a cikkekhez
technologytutorial

Firebase — a teljes platform áttekintése

Zsaga
#featured#firebase#baas#firestore#authentication#security-rules#cloud-functions#hosting#storage#fcm#app-check#extensions
Firebase platform áttekintés — Firestore, Auth, Hosting, Storage, Functions és FCM egy központi projekt-csomópont körül
A Firebase szolgáltatások egy projekt köré rendeződnek
Mit tanulsz
  • firebaseBevezető

01 — Bevezetés

Mi a Firebase, és miért különbözik?

A Firebase egy Backend-as-a-Service platform a Google-tól — de ez a leírás kevés. A lényeg az, hogy a benne lévő szolgáltatások együtt dolgoznak, és ez teljesen megváltoztatja, hogyan építünk alkalmazást.
A hagyományos webalkalmazás úgy néz ki, hogy van egy frontend (Angular, React, Vue), egy backend API (Node, Java, Python), egy adatbázis (PostgreSQL, MySQL), egy fájltároló (S3 vagy helyi), egy bejelentkezési réteg (saját JWT, Auth0), és sok integrációs kód, ami ezeket összeköti. A Firebase ehhez képest becsomagolja az egész köztes réteget: a kliens közvetlenül beszél az adatbázissal, közvetlenül feltölt fájlokat, közvetlenül bejelentkezik, és csak akkor írunk szerveroldali kódot, ha valami olyat kell csinálnunk, amit a kliens nem tehet meg.
Ez két dolgot ad cserébe: lényegesen rövidebb fejlesztési időt egy első működő változatig vagy egy KKV-méretű alkalmazásig, és egészen más biztonsági modellt, mert most a kliens közvetlenül olvas és ír az adatbázisba. Ez utóbbi miatt válik a Security Rules központi kérdéssé — erről külön szekció szól.
Info
A Firebase 2014 óta a Google-é, de a platform továbbra is külön márka — saját Console-lal, dokumentációval, CLI-vel. A motor mögött többnyire Google Cloud szolgáltatások vannak: Firestore = Google Cloud Firestore, Functions = Cloud Functions, Storage = Google Cloud Storage. Aki ismeri a GCP-t, az itt is otthon van.

Mire jó és mire nem?

Erre érdemes őszinte választ adni, mielőtt belemerülünk:
  • Nagyon jó: valós idejű, közös munkára épülő alkalmazások, mobilra szánt appok, KKV-s belső rendszerek, első működő változatok, prototípusok, kis-közepes SaaS termékek, statikus weboldalak dinamikus elemekkel, IoT dashboardok.
  • Vegyes kép: bonyolult relációs adatmodellel rendelkező rendszerek, nagy mennyiségű analitikai lekérdezés, olyan üzleti logika, ami sok kollekcióból összerakott adatokat igényel.
  • Inkább ne: tranzakcióigényes pénzügyi rendszerek erős konzisztencia-garanciákkal, nagyon nagy adatmennyiségű ETL pipeline-ok, klasszikus BI-rendszerek, és olyan vállalati környezet, ami nem szeretne egyetlen szolgáltatótól függeni.
Mit tanulsz
  • firebaseBevezető

02 — Szerkezet

Projekt, app, környezet

A Firebase mindent egy projektbe szervez. Ez a projekt a legfelső szintű egység — alatta vannak az appok (web, iOS, Android, Flutter), és minden szolgáltatás (Firestore, Auth, stb.) ehhez a projekthez tartozik.
Egy Firebase projekt valójában egy Google Cloud projektre épül. Ez azért fontos, mert minden Firebase-szolgáltatást a GCP Console-ban is látsz, és minden számlázás a GCP fiókon keresztül megy. Egy Firebase projekten belül több app is lehet:
firebase-projectplaintext
my-saas-prod                          # project ID
├── apps
│   ├── web         # Angular frontend
│   ├── ios         # Swift app
│   ├── android     # Kotlin app
│   └── admin-web   # second Angular app, admin UI
├── firestore       # shared database for all 4 apps
├── auth            # shared user base
├── storage         # shared file storage
├── functions       # shared backend code
└── hosting
    ├── site:web         # app.example.com
    └── site:admin       # admin.example.com
A négy app ugyanazt a Firestore adatbázist látja, ugyanazt a felhasználói bázist használja, ugyanazokat a fájlokat éri el. Emiatt jó a Firebase több platformot kiszolgáló termékekhez — egyszer megtervezed az adatszerkezetet, és minden frontend ugyanazt használja.

Környezetek kezelése

A Firebase nem ismer „dev/staging/prod" kapcsolót egy projekten belül. Minden környezet egy különálló Firebase projekt. Ez elsőre furcsának tűnhet, de pont ez akadályozza meg, hogy a fejlesztés véletlenül éles adatot írjon.
.firebasercjson
{
  "projects": {
    "default": "my-saas-dev",
    "dev":     "my-saas-dev",
    "staging": "my-saas-staging",
    "prod":    "my-saas-prod"
  }
}
Ezután CLI-ből a firebase use prod parancs után minden következő deploy az éles projektre megy.
Tipp
Helyi fejlesztéshez ne használj éles projektet, még olvasásra sem. A Firebase Local Emulator Suite egy helyben futó, teljes mock-szerver: Firestore, Auth, Functions, Storage, Database, Pub/Sub — mindegyik futtatható helyben, internet nélkül, ingyen. Egy firebase emulators:start elindít mindent, és az SDK-k automatikusan a helyi végpontokra csatlakoznak, ha így állítod be.
Mit tanulsz
  • firestoreKözéphaladó

03 — Firestore

A központi adatbázis: Firestore

A Firestore egy NoSQL document adatbázis, ami valós időben szinkronizál a klienssel. A lényege nem a NoSQL — hanem hogy a kliens közvetlenül „feliratkozhat" egy lekérdezésre, és minden változás magától, push-szal érkezik a frontendre.

Adatszerkezet: kollekció — dokumentum — kollekció

A Firestore két alapegysége a kollekció (collection) és a dokumentum (document). Egy kollekció dokumentumok gyűjteménye, egy dokumentum pedig egy JSON-szerű, kulcs-érték párokból álló objektum, aminek lehetnek alkollekciói. A hierarchia ezért mindig páros mélységű: kollekció / dokumentum / kollekció / dokumentum / ....
firestore-data-treeplaintext
users                              # collection
├── usr_abc123                     # document
│   ├── displayName: "Anna Kovács"
│   ├── email: "anna@example.com"
│   ├── createdAt: Timestamp
│   └── orders                     # subcollection
│       ├── ord_001 { ... }
│       └── ord_002 { ... }
└── usr_xyz789
    └── ...

Valós idejű feliratkozások

A Firestore legfontosabb tulajdonsága nem a NoSQL — hanem az, hogy minden lekérdezés feliratkozható. Egyszer megmondod, hogy „kérem az aktív rendelések listáját", és onnantól a Firestore minden változást magától elküld a kliensnek WebSocketen keresztül. Nincs polling, nincs frissítés-gomb, nincs cache-érvénytelenítés.
orders.service.tstypescript
import { collection, query, where, onSnapshot } from 'firebase/firestore';

const q = query(
  collection(db, 'orders'),
  where('status', '==', 'active')
);

// Subscribe — every change arrives via push
onSnapshot(q, (snap) => {
  const orders = snap.docs.map(d => ({ id: d.id, ...d.data() }));
  // UI update
});
Ha egy másik felhasználó (vagy egy Cloud Function) ír az adatbázisba, és a változás beleesik a lekérdezésbe, az onSnapshot callback magától újra lefut. Emiatt egy közös munkára épülő alkalmazás készítése egészen egyszerűvé válik — nem kell külön WebSocket szervert írnod, nem kell Pub/Sub-ot, és nem kell broadcast logikát sem.

A lekérdezések korlátai

A Firestore lekérdezései szándékosan korlátozottak — mert minden lekérdezésnek azonos idő alatt kell lefutnia, függetlenül attól, mekkora az adatbázis. Ezt két dolog teszi lehetővé:
  1. Minden mező magától indexelt — egyszerű lekérdezések azonnal mennek.
  2. Összetett index (composite index) kell minden olyan lekérdezéshez, ami több mezőre szűr vagy rendez egyszerre. Ezeket vagy egy firestore.indexes.json-ben kell deklarálnod, vagy az első hibaüzenet után kapsz egy linket a Console-ban, ami egy kattintással létrehozza.
Amit nem tudsz csinálni a Firestore-ban:
  • Joinokat. Ha egy referenciát fel akarsz oldani, az külön lekérdezés.
  • Tetszőleges mező mentén történő aggregációkat (csak count(), sum(), average() működik, és ezek külön költségen).
  • Full-text keresést. Ehhez Algolia, Typesense, vagy Cloud Function + Elastic kell.
  • Több mezőn átnyúló OR kombinációkat (csak nemrég, és korlátozottan).
Figyelem
A Firestore díjszabása minden olvasott dokumentum után fizet, nem a lekérdezés bonyolultsága számít. Ezért az adatok megtervezése sokszor egyenlő a teljesítmény-optimalizálással — denormalizálni kell, ahogy a NoSQL világban általában szokás. Egy rosszul kitalált kollekció-szerkezet a hónap végén egy nem várt számlában jelentkezik.
Mit tanulsz
  • firebaseKözéphaladó

04 — Realtime Database

Realtime Database — és mikor kell?

A Firebase eredeti adatbázisa, ami a Firestore előtt készült. Ma is él, és néhány konkrét helyzetben jobb, mint az utódja — a legtöbb esetben azonban már nem ez az alapértelmezett választás.
A Realtime Database egy nagy JSON fa. Nincs benne kollekció és dokumentum — csak egyetlen, gyökértől induló fa, amit elérési útvonalakon keresztül érsz el. Egyszerűbb modell, és néhány dologban gyorsabb, mint a Firestore.
SzempontRealtime DatabaseFirestore
AdatmodellEgy JSON faKollekciók és dokumentumok
LekérdezésekKorlátozott — egy mezőre lehet szűrniTöbb mezős, indexelt
Skálázhatóság~200k egyidejű kapcsolatGyakorlatilag korlátlan
RégiókEgy régió per adatbázisTöbb régiós is lehet
Késleltetés (kis írás)Általában alacsonyabbÁltalában magasabb
Offline támogatásMobil + webMobil + web (jobb)
PricingSávszélesség + tárhely alapúMűveletek + tárhely alapú
A gyakorlatban: ha klasszikus üzleti adatokat tárolsz — felhasználók, rendelések, termékek, tartalom — akkor Firestore. Ha gyakori, kicsi és valós idejű változásokat kell sok kliensnek elküldeni — például chat alkalmazásban gépelés-jelzőt, jelenlét-állapotot, élő pozíció követést, többjátékos játékot — akkor a Realtime Database sokszor jobb választás. Egy-egy írás gyorsabb, és sok kis művelet esetén a költsége kiszámíthatóbb.
Több projekten mindkettőt használjuk: Firestore a fő adatra, Realtime Database a jelenlétre és a gyorsan változó, mulandó állapotokra. A Firebase ezt nem akadályozza, sőt — egy projekten belül mindkettő ugyanúgy hitelesít, és ugyanazt a Security Rules motort használja.
Mit tanulsz
  • firebase-authKözéphaladó

05 — Authentication

Authentication — identitás kiszervezve

A Firebase Auth nem csak egy egyszerű bejelentkező-form mögötti backend. Egy teljes értékű identitásszolgáltató, ami támogatja az email + jelszó párost, a közösségi belépéseket, a telefonszámos hitelesítést, az anonim felhasználókat, a saját JWT-t és a több bérlős (multi-tenant) felépítést is. Az általa kibocsátott identitással minden más Firebase szolgáltatás tud dolgozni.

Mi van a dobozban?

  • Email + jelszó regisztráció és bejelentkezés, beleértve a megerősítő emailt és a jelszó-visszaállítási folyamatot.
  • OAuth szolgáltatók: Google, Apple, Facebook, Microsoft, Twitter, GitHub, Yahoo, és bármilyen OpenID Connect-kompatibilis külső azonosító.
  • Telefonszámos hitelesítés SMS-ben küldött kóddal.
  • Anonim felhasználó — kap egy ID-t, hogy a regisztráció előtti tevékenysége is követhető legyen, később pedig összevonható egy „rendes" fiókkal.
  • Saját token — egy saját azonosítórendszer beépíthető úgy, hogy a szerveren kibocsátott JWT-t a Firebase elfogadja.
  • Több bérlős üzemmód: egy projekten belül több külön bérlőt lehet létrehozni (Firebase Auth with Identity Platform — csak Blaze planon).
login.tstypescript
import { getAuth, signInWithEmailAndPassword } from 'firebase/auth';

const auth = getAuth();

try {
  const cred = await signInWithEmailAndPassword(auth, email, password);
  const token = await cred.user.getIdToken();
  // The token is automatically attached to every Firestore/Storage call
} catch (err) {
  // auth/wrong-password, auth/user-not-found, ...
}

Custom claims — saját szerepkörök

A felhasználói objektum alap mezőin túl (uid, email, displayName) a Firebase Auth lehetőséget ad arra, hogy szerver oldalról saját mezőket írj a JWT-be. Ezeket „custom claims"-nek hívják, és a Security Rules-ban közvetlenül elérhetők — például egy admin: true alapján egy az egyben eldönthető, ki éri el az admin felületet.
setAdminRole.ts (Cloud Function)typescript
import { getAuth } from 'firebase-admin/auth';

await getAuth().setCustomUserClaims(uid, {
  role: 'admin',
  tenantId: 'acme-corp',
});

// The user receives the new claims on the next token refresh
// Client side: await user.getIdToken(true) forces a refresh
Megjegyzés
A custom claims mérete korlátozott (max 1000 byte), és csak ritkán változó adatokra való. A gyakran változó felhasználói beállításokat — például preferenciákat — a Firestore-ban tartsd, ne a JWT-ben.
Mit tanulsz
  • security-rulesKözéphaladó

06 — Security Rules

Security Rules — a backend a klienshez közelebb

Ha a kliens közvetlenül kommunikál a Firestore-ral, akkor a megszokott backend-rétegbeli jogosultságkezelés helyett valami másnak kell védenie az adatot. Ez a Security Rules — egy szabálynyelv, amiben deklaratívan leírod, hogy ki, mit és milyen feltételek mellett olvashat vagy írhat.
A Security Rules fontosabb, mint amilyennek elsőre tűnik. Ez maga a backend egy tipikus Firebase alkalmazásban — és ha rossz vagy hiányzik, az adatod bárki előtt nyitva áll, aki ki tudja olvasni a kliens konfigurációját.
firestore.rulesplaintext
rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {

    // users/{uid} document: only the owner can read or write
    match /users/{uid} {
      allow read, write: if request.auth.uid == uid;
    }

    // orders: a user sees only their own; admin sees and writes all
    match /orders/{orderId} {
      allow read:  if request.auth.uid == resource.data.userId
                || request.auth.token.role == 'admin';
      allow create: if request.auth != null
                 && request.resource.data.userId == request.auth.uid;
      allow update, delete: if request.auth.token.role == 'admin';
    }
  }
}
A Rules nyelv tud:
  • A bejelentkezés állapotát ellenőrizni (request.auth).
  • A custom claimekre hivatkozni (request.auth.token.role).
  • A dokumentum aktuális (resource.data) és új (request.resource.data) értékét összehasonlítani.
  • Más dokumentumokat is beolvasni a szabály kiértékelése közben (get(/databases/.../docs/...)) — de ez minden hívás 1-1 olvasásnak számít a számlán.
  • Függvényeket definiálni a szabályok újrafelhasználhatóságához.

Mit nem tud?

  • Bonyolult üzleti validációt (pl. „a rendelés teljes értéke ne legyen több, mint a hitelkeret" — ezt már Cloud Function-be kell tenni).
  • Külső API hívást.
  • Tranzakciós, több dokumentumot átfogó ellenőrzést.
Figyelem
A nyitott (allow read, write: if true;) Rules a leggyakoribb Firebase biztonsági baleset forrása. A Firebase Console rendszeresen küld figyelmeztetést, ha a Rules-od kockázatosan engedékeny — ezeket vedd komolyan. Élesítés előtt minden kollekcióra legyen egy konkrét szabály, és teszteld le emulátoros unit tesztekkel.

A Firestore Security Rules egy kis API-réteg, csak deklaratívan leírva. Ha úgy gondolsz rá, mint backend kódra — csak más szintaxissal —, akkor jó irányból közelítesz hozzá.

Mit tanulsz
  • firebase-hostingKözéphaladó

07 — Hosting

Hosting — statikus tárhely CDN-nel

A Firebase Hosting egy világméretű CDN, ami statikus fájlokat (HTML, CSS, JS, képek) szolgál ki, és nemrég a Cloud Run-on keresztül a dinamikus rendereléshez is integrálódott. Egyszerű, gyors, és az ingyenes csomagjában is használható éles forgalomra.

Mire használjuk?

  • Single Page Application-ök kiszolgálására (Angular, React, Vue dist mappa).
  • Statikus oldalakra (Astro, Next.js export, Hugo, sima HTML).
  • Server-Side Rendering-hez Cloud Run vagy Cloud Functions backenddel.
  • Több site együttes hosztolása — egy projekten belül több domain (pl. app.example.com, admin.example.com, blog.example.com).

Konfiguráció

firebase.jsonjson
{
  "hosting": [
    {
      "target": "web",
      "public": "dist/web/browser",
      "ignore": ["firebase.json", "**/.*"],
      "rewrites": [
        { "source": "/api/**", "function": "api" },
        { "source": "**", "destination": "/index.html" }
      ],
      "headers": [
        {
          "source": "**/*.@(js|css|woff2)",
          "headers": [{ "key": "Cache-Control", "value": "max-age=31536000, immutable" }]
        }
      ]
    }
  ]
}
A két lényeges feature:
  • Átirányítás (rewrite) Cloud Functions-ra vagy Cloud Run-ra — egyetlen domain alól mind a statikus, mind a dinamikus tartalom kiszolgálható, beleértve az API-t és az SSR-t.
  • Atomi deploy — minden kiadás egy új verzióként megy ki, és a Console-ról egy kattintással visszaállítható egy korábbi verzió. Vannak preview-csatornák is — minden PR-hez generálható egy ideiglenes URL.
Info
A Firebase Hosting az ingyenes Spark planon is 10 GB tárhelyet és napi 360 MB forgalmat ad — sok KKV-s alkalmazás bőven elfér ebben. SSL tanúsítványt magától intéz, és saját domain is beállítható.
Mit tanulsz
  • cloud-functionsKözéphaladó

08 — Cloud Functions

Cloud Functions — szerveroldali kód, ha kell

A Firebase Functions a serverless kompromisszum: nincs szerver, amit fenn kell tartanod, csak függvényeket írsz, és azok eseményekre futnak le. Itt él minden olyan logika, amit a kliens nem hajthat végre biztonságosan.

Trigger típusok

TriggerMire használjuk
HTTPS / CallableAPI végpont, kliensből hívható, típusos függvény
FirestoreonCreate, onUpdate, onDelete egy kollekcióra
AuthÚj felhasználó létrejöttekor (pl. üdvözlő email, alapértelmezett user-doc létrehozása)
StorageFájl feltöltése után (pl. képfeldolgozás, kicsinyített változat készítése)
Pub/Sub / SchedulerIdőzített háttérfeladatok (cron-szerű ütemezés)
Realtime DBÚtvonal-eseményekre
Remote ConfigKonfiguráció változására
functions/src/index.tstypescript
import { onDocumentCreated } from 'firebase-functions/v2/firestore';
import { onCall, HttpsError } from 'firebase-functions/v2/https';
import { onSchedule } from 'firebase-functions/v2/scheduler';

// 1) Firestore trigger — send confirmation email on new order
export const onOrderCreated = onDocumentCreated('orders/{orderId}', async (event) => {
  const order = event.data?.data();
  await sendConfirmationEmail(order);
});

// 2) Callable — secured operation, admin only
export const deleteUser = onCall(async (request) => {
  if (request.auth?.token.role !== 'admin') {
    throw new HttpsError('permission-denied', 'Admin only');
  }
  // ...
});

// 3) Scheduled — archive every night at 02:00
export const nightlyArchive = onSchedule('0 2 * * *', async () => {
  // ...
});

Cloud Functions v2 — ami most az alapértelmezett

A v2 generáció Cloud Run-on fut a háttérben (a v1 GCF-en futott). Ez konkrét különbségeket jelent: egy instance párhuzamosan tud több kérést kezelni (a v1 mindig csak egyet egyszerre), nagyobb a memória- és CPU-limit (akár 32 GB és 8 vCPU), általában rövidebb a cold start, és van min instance beállítás, ami a cold startot teljesen kiküszöböli — ha a költséget vállalod érte.
Költség
A Cloud Functions csak a Blaze (pay-as-you-go) planon érhető el. Ingyen-tier ezen belül is van — havi 2 millió hívás —, de Blaze nélkül egyáltalán nincs Functions. Ha az architektúra Functions-t igényel, akkor Blaze-re kell váltani.
Mit tanulsz
  • cloud-storageKözéphaladó

09 — Cloud Storage

Cloud Storage — fájltároló Security Rules-szal

A Firebase Storage egy Google Cloud Storage bucket, kliens-oldali SDK-val, és a Firestore-éval megegyező szabálynyelvi védelemmel. Képek, dokumentumok, videók, bármilyen bináris fájl — közvetlenül a kliensből fel- és letölthető, hitelesítéssel ellenőrizve.
upload.tstypescript
import { getStorage, ref, uploadBytes, getDownloadURL } from 'firebase/storage';

const storage = getStorage();
const avatarRef = ref(storage, `users/${user.uid}/avatar.jpg`);

const snap = await uploadBytes(avatarRef, file);
const url  = await getDownloadURL(snap.ref);

// `url` is a public download link, token-protected — safe to store in Firestore

Storage Rules

storage.rulesplaintext
rules_version = '2';

service firebase.storage {
  match /b/{bucket}/o {

    // Own avatar: max 5 MB, image type, only the user themselves
    match /users/{uid}/avatar.{ext} {
      allow read:  if true;
      allow write: if request.auth.uid == uid
                && request.resource.size < 5 * 1024 * 1024
                && request.resource.contentType.matches('image/.*');
    }
  }
}
A Firestore Rules-hoz hasonló nyelv, de Storage-specifikus mezőkkel: request.resource.size (a feltöltendő fájl mérete), request.resource.contentType (MIME típus) és a metadata. A Firestore Rules-szal ellentétben a Storage Rules nem tud Firestore-ból olvasni — ha bonyolultabb döntés kell, az Storage trigger Function-ben, utólagos feldolgozással intézendő.
Mit tanulsz
  • firebaseKözéphaladó

10 — Cloud Messaging

FCM — push notification ingyen, korlátlan

A Firebase Cloud Messaging push üzeneteket küld iOS, Android és web böngészőkbe. Spark planon is korlátlan és ingyenes — ami egy olyan szolgáltatástól, ami máshol sok pénzbe kerül, szokatlanul nagylelkű.
Az FCM kétféle üzenetet ismer: notification message (ezt a rendszer maga jeleníti meg, akkor is, ha az app nem fut), és data message (ezt csak az app dolgozza fel, és dönthet úgy, hogy nem is mutat semmit a felhasználónak). A kettő keverhető.
sendNotification.tstypescript
import { getMessaging } from 'firebase-admin/messaging';

await getMessaging().send({
  token: userDeviceToken,
  notification: {
    title: 'New order received',
    body:  '#ORD-2026-0421 — Anna Kovács',
  },
  data: { orderId: 'ord_xyz' },
});
Az FCM támogatja a topikokat is — egy üzenettel egyszerre több ezer eszköz elérhető, ha azok feliratkoztak egy topic-ra. Ez jól jön tömeges értesítésekhez (pl. „új cikk a kedvenc csapatodról").
Mit tanulsz
  • firebaseKözéphaladó

11 — App Check

App Check — API védelme a kliensen kívülről

Az App Check arra a problémára ad választ, amire a Security Rules nem tud: hogyan akadályozod meg, hogy valaki bottal vagy egy másik alkalmazással beszéljen a Firestore-oddal? A válasz: a kérésnek bizonyítania kell, hogy az „eredeti" appból érkezik.
Az App Check működése egyszerű: a kliens minden kéréshez egy rövid életű tokent állít elő (web-en reCAPTCHA Enterprise, Androidon Play Integrity, iOS-en DeviceCheck/App Attest segítségével), és ezt a tokent a Firebase szerver ellenőrzi. Ha egy szolgáltatáson be van kapcsolva az App Check kikényszerítése, akkor a token nélküli kéréseket eldobja — a Security Rules ki sem értékelődik.
Tipp
Élesítés előtt minden Firebase szolgáltatáson kapcsold be az App Check kikényszerítését (Firestore, Storage, Functions, Realtime Database). A költsége nulla, a védelem viszont jelentős. Helyi fejlesztéshez a debug token mechanizmus oldja meg, hogy a fejlesztői gép is működjön.
Mit tanulsz
  • firebaseKözéphaladó

12 — Extensions

Extensions — előre csomagolt funkcionalitás

A Firebase Extensions előre megírt Cloud Functions sorozatok, amik egy kattintással telepíthetők és előre beállíthatók. A Stripe fizetés, képméretezés, full-text keresés Algoliával — mind egy-egy Extension formájában érhető el.
Néhány gyakori Extension:
  • Resize Images — a feltöltött képekből automatikusan kicsinyített változatokat készít (Storage trigger).
  • Run Payments with Stripe — Stripe Checkout, előfizetés, webhook-kezelés egy Firestore kollekcióra leképezve.
  • Trigger Email — ha egy Firestore dokumentumot létrehozol, küldi az emailt SendGrid-en vagy SMTP-n keresztül.
  • Translate Text — egy Firestore mező értékét automatikusan lefordítja Google Translate-tel.
  • Search with Algolia — a Firestore kollekciót szinkronban tartja egy Algolia indexszel a full-text kereséshez.
  • Build Chatbot with Gemini — Vertex AI / Gemini integráció.
Az Extensions előnye nem csak a gyorsaság — hanem az is, hogy a karbantartást a Firebase csapat (vagy a partner) végzi. Ha az Algolia API változik, az Extension verziófrissítéssel követi, és nem neked kell utána szaladnod.
Megjegyzés
Az Extensions Cloud Functions-re épül, ezért szintén csak Blaze planon érhető el. A használat költsége a Functions/Firestore/Storage költségén felül a partnerszolgáltatás díja (pl. Stripe tranzakciós díj, Algolia havi díj).
Mit tanulsz
  • firebaseBevezető

13 — Pricing

Spark vs Blaze — fizetés a Firebase-ért

A Firebase két csomagot kínál: Spark (ingyenes, kemény napi limitekkel) és Blaze (pay-as-you-go, elég nagylelkű ingyenes kerettel). A választás nem a tervezett méretről szól — hanem arról, hogy milyen szolgáltatásokat akarsz használni.
SzolgáltatásSpark (ingyen)Blaze (pay-as-you-go)
Firestore50k olvasás / 20k írás / nap, 1 GBKorlátlan, használat alapján
Authentication50k MAU phone, korlátlan többiKorlátlan
Hosting10 GB, 360 MB/nap forgalom10 GB ingyenes + extra
Storage5 GB, 1 GB/nap letöltés5 GB ingyenes + extra
Functionsnincs2M hívás / hó ingyen
Extensionsnincselérhető
FCMKorlátlanKorlátlan
App Check10k ellenőrzés / hó10k ingyen + extra
A Blaze-on az „ingyenes tier" megmarad — ha egy Blaze projekt nem éri el a Spark limitjeit, a számla 0 forint. A Blaze tehát nem azt jelenti, hogy „mostantól fizetsz", hanem hogy „ha túllépsz, akkor fizetsz". A lényeg, hogy a Functions és az Extensions egyáltalán nem érhető el Sparkon.
Költség-figyelmeztetés
Éles Blaze projektnél állíts be budget alertet a GCP Billing-ben. Ha egy Cloud Function végtelen ciklusba kerül (pl. önmagát triggerelő Firestore write), a számla pillanatok alatt elszállhat. Egy 500 EUR / nap-os alert nem állítja meg a futást, de figyelmeztet, mielőtt a hónap végén meglepetés érne.

14 — Konklúzió

Mikor érdemes választani?

A Firebase nem mindenre jó válasz, és nem is reklámozza magát annak. A kérdés mindig az: a saját projekted hol helyezkedik el a Firebase erősségeihez képest?
A Firebase három területen verhetetlen: fejlesztési sebesség az első működő változatig, valós idejű, közös munkára épülő felhasználói élmény kis-közepes léptékben, és több platform közti kódmegosztás (web + mobil, közös backend nélkül). Ha a projekted ezek közül valamelyikbe esik, akkor a Firebase jó eséllyel megold néhány olyan problémát, amit egyébként magadnak kellene megoldanod.
Amikor érdemes másik megoldást is mérlegelni: bonyolult relációs adatmodell (sok kollekciókon átnyúló olvasással, ami a Firestore-ban drága), analitikai munkaterhelés (a Firestore-t BigQuery-be kell exportálni hozzá), szigorú tranzakciós garanciák (a Firestore tranzakciók működnek, de nem helyettesítik a Postgres-t), és egy szolgáltatótól független infrastruktúra-igény (a Firebase-ből nehéz kilépni — minden út a Google Cloud-ra mutat).
A következő cikkekben — ennek a tudásbázis-cikknek a folytatásaiban — egy-egy szolgáltatást viszünk mélyebbre: külön cikk lesz a Firestore adat-modelltervezésről, külön a Security Rules teszteléséről és a custom claims mintákról, külön a Functions architektúrákról, és külön a Hosting + Functions kombinációval épített SSR megoldásokról.

A Firebase nem egy adatbázis. Ez egy döntés: a backend nagy részét nem akarod megírni — cserébe pedig elfogadod a Firebase által szabott határokat.

Vissza az elejére