Firebase er en av de raskeste veiene fra kode til produksjon. For portfoliosiden min — ryanomar.com — er det det jeg bruker for hosting. Én kommando, og siden er live. Ingen Nginx-konfigurasjon, ingen SSL-sertifikater å fornye, ingen servere å vedlikeholde.
Men Firebase er også en plattform du kan vokse ut av. Denne guiden handler om hva Firebase gjør godt, når du treffer grensene, og hva du bør vurdere før du bygger hele arkitekturen din rundt det.
Firebase Hosting for statiske sider
For portofolioen min er Firebase Hosting ideelt. Siden er en Next.js-app som eksporteres statisk — HTML, CSS, JavaScript og bilder. Firebase serverer dette fra et globalt CDN med automatisk SSL og HTTP/2.
Konfigurasjonen er minimal. Hele oppsettet lever i én fil:
{
"hosting": {
"public": "out",
"ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
"rewrites": [
{
"source": "**",
"destination": "/index.html"
}
],
"headers": [
{
"source": "**/*.@(js|css)",
"headers": [
{
"key": "Cache-Control",
"value": "public, max-age=31536000, immutable"
}
]
},
{
"source": "**/*.@(jpg|jpeg|png|gif|webp|svg|ico)",
"headers": [
{
"key": "Cache-Control",
"value": "public, max-age=86400"
}
]
}
]
}
}rewrites-regelen sender alle forespørsler til index.html, som er nødvendig for client-side routing i en SPA. Cache-headers er satt aggressivt for statiske assets — JavaScript og CSS med content hashes får et år, bilder får en dag. Dette gir rask lasting for returnerende besøkende uten at du trenger å tenke på cache-invalidering.
Deployment er firebase deploy. Det tar under 10 sekunder. For en portofolioside er dette alt du trenger.
Firestore: Styrker og begrensninger
Firestore er Firebases NoSQL-database. Den er sanntidsoppdatert, skalerer automatisk, og krever ingen serveradministrasjon. For visse brukstilfeller er den fantastisk. For andre er den et fengsel.
Styrkene er reelle. Sanntidslyttere er innebygd — du skriver onSnapshot(), og klienten oppdateres automatisk når data endres. For chat-applikasjoner, dashboards, og collaborative tools er dette utrolig kraftig. Offline-støtte kommer gratis — Firestore cacher data lokalt og synkroniserer når tilkoblingen er tilbake.
Men begrensningene biter hardt. Firestore er en dokumentdatabase. Det finnes ingen JOINs. Hvis du trenger å hente en bruker med alle kursene sine og alle quizresultatene for hvert kurs, må du gjøre tre separate spørringer og sette sammen dataen selv. I PostgreSQL er det én SQL-spørring.
Prismodellen kan overraske. Du betaler per lese-, skrive- og slette-operasjon. En enkelt side som viser en liste med 50 elementer koster 50 leseoperasjoner. Legg til sanntidslyttere på hvert element, og kostnadene kan eskalere raskt. Jeg har sett prosjekter der Firestore-regningen oversteg kostnaden for en dedikert PostgreSQL-server — med mye dårligere spørringfleksibilitet.
Spørringbegrensninger er frustrerende. Du kan ikke filtrere på et felt og sortere på et annet uten å opprette en sammensatt indeks. Du kan ikke gjøre !=-spørringer effektivt. Full-text search finnes ikke — du trenger en ekstern tjeneste som Algolia.
Firestore Security Rules
En av Firebases styrker er at du kan definere tilgangsregler direkte i databasen, uten en backend-server. For enkle applikasjoner kan dette erstatte et helt autoriseringslag:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read: if request.auth != null;
allow write: if request.auth.uid == userId;
}
match /posts/{postId} {
allow read: if true;
allow create: if request.auth != null
&& request.resource.data.authorId == request.auth.uid
&& request.resource.data.title is string
&& request.resource.data.title.size() <= 200;
allow update: if request.auth.uid == resource.data.authorId;
allow delete: if request.auth.uid == resource.data.authorId
|| get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin';
}
}
}Reglene kjører server-side, så de kan ikke omgås fra klienten. Du kan validere datastruktur, sjekke autentisering, og til og med lese andre dokumenter for å sjekke roller. Men kompleksiteten vokser raskt. Når reglene dine er hundrevis av linjer lange og du begynner å duplisere logikk mellom security rules og Cloud Functions — da er det et tegn på at du trenger en ordentlig backend.
Firestore vs. PostgreSQL: Når du bør migrere
Etter å ha brukt begge i ulike prosjekter, har jeg en klar mental modell:
Bruk Firestore når:
- Applikasjonen er sanntids-tung (chat, samarbeid, live dashboards)
- Datmodellen er enkel og dokument-orientert
- Du vil unngå å drifte en database
- Teamet er lite og frontend-tungt
Bruk PostgreSQL når:
- Du trenger komplekse spørringer med JOINs og aggregeringer
- Datakonsistens er kritisk (transaksjoner over flere tabeller)
- Du har relasjonelle data som naturlig passer i tabeller
- Kostnadskontroll er viktig — PostgreSQL koster det samme uansett antall spørringer
For portofolioen min er Firebase Hosting perfekt — det er en statisk side uten database. Hadde jeg bygget en full applikasjon med brukerdata, ville jeg startet med Firestore for prototypen og migrert til PostgreSQL når datakravene ble komplekse.
Grensene for serverless
Firebase er et serverless-produkt, og det bærer med seg de generelle begrensningene til serverless-arkitekturer.
Vendor lock-in er reell. Firestore har et proprietært API. Flytter du bort fra Firebase, må du skrive om alt som snakker med databasen. Firebase Authentication, Cloud Functions, Firestore — alt er tett integrert. Det er bekvemt når du er inne, men smertefullt når du vil ut.
Cold starts i Cloud Functions. Firebase Cloud Functions kjører på Google Cloud Functions under panseret. En funksjon som ikke har vært kalt på en stund tar 1-3 sekunder å starte opp. For en API som brukere forventer svarer umiddelbart, er det merkbart.
Debugging er vanskelig. Når noe feiler i Firestore Security Rules eller Cloud Functions, er feilmeldingene ofte kryptiske. Lokal utvikling med Firebase Emulator Suite hjelper, men det er fortsatt vanskeligere å debugge enn en Node.js-server du kjører selv.
Avsluttende tanker
Firebase er et utmerket verktøy for riktig brukstilfelle. For min portofolio gir det en friktionsfri hosting-opplevelse. For prototyper og MVPer kan det spare uker med backend-utvikling.
Men gå inn med åpne øyne. Forstå prismodellen, vær bevisst på vendor lock-in, og ha en plan for når du vokser ut av det. Firebase er en utmerket startlinje — men det er sjelden mållinja.