Firebase Hosting og Cloud Firestore til en AI-bygget app

Hvad løser Hosting og Firestore?

Start med miljøer og placering

Brug separate Firebase-projekter til udvikling og produktion. Hvert projekt får sin egen Hosting-side, database, brugere, regler og forbrug. Det gør det muligt at teste ændringer uden at arbejde direkte i kundernes data.

• Vælg Firestore-region med omtanke. Placeringen kan ikke bare flyttes senere. Vælg tæt på brugerne og de øvrige backendressourcer.
• Brug projekt-aliaser. Navne som dev og prod gør deploymentmålet tydeligt.
• Sæt budgetalarmer. De stopper ikke automatisk forbruget, men varsler, før en fejl eller uventet trafik bliver dyr.
• Begræns projektroller. Få personer bør kunne ændre regler, fakturering og produktionsdata.

Opsæt Firebase Hosting

Installer Firebase CLI, log ind med den rigtige konto, og kørfirebase init hostingi projektets rodmappe. Vælg appens buildmappe som public directory. For Vite er det normalt dist; andre frameworks kan bruge et andet navn.

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      { "source": "**", "destination": "/index.html" }
    ]
  },
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  }
}

Rewrite-reglen sender ukendte URL'er tilindex.html, så client-side routing virker i en single-page app. Den er ikke rigtig for alle sites: SSR-frameworks og serverfunktioner kræver en anden hostingarkitektur.

Byg før I deployer

1. 1. Kør projektets tests og produktionsbuild.
2. 2. Kontrollér lokalt, at buildmappen indeholder den forventede app.
3. 3. Brug en Hosting preview channel til at gennemgå ændringen på en midlertidig URL.
4. 4. Deploy kun Hosting med firebase deploy --only hosting.
5. 5. Smoke-test login, beskyttede sider og de vigtigste dataflows på den live URL.

Når det manuelle flow er stabilt, bør deployment flyttes til GitHub Actions. Produktion bør først udgives efter et grønt build og helst fra en beskyttet branch eller et godkendt GitHub Environment.

Forstå Firestores datamodel

Firestore er en NoSQL-dokumentdatabase. Data ligger i dokumenter, og dokumenter ligger i collections. Der er ikke joins som i en traditionel SQL-database, så datamodellen skal bygges efter de forespørgsler og adgangsregler, appen faktisk skal bruge.

• Dokumenter: Små JSON-lignende poster med felter, fx titel, status og oprettelsestidspunkt.
• Collections: Grupper af dokumenter, fx virksomheder, brugere eller opgaver.
• Subcollections: Voksende data under et dokument, fx opgaver under en virksomhed.
• Indekser: Gør forespørgsler hurtige, men fylder og påvirker omkostning og skrivearbejde.

Læg ikke en ubegrænset liste af opgaver, beskeder eller historik i ét dokument. Brug en collection eller subcollection, så hvert element kan læses, opdateres og sikres separat. Husk også, at sletning af et dokument ikke automatisk sletter dets subcollections.

Skriv data med stabile felter

Firestore håndhæver ikke et fast skema. Det gør det hurtigt at komme i gang, men en AI-genereret app kan let ende med forskellige feltnavne og datatyper i samme collection. Definér derfor de forventede felter i kode, tests og Security Rules.

import { initializeApp } from "firebase/app";
import {
  addDoc,
  collection,
  getFirestore,
  serverTimestamp,
} from "firebase/firestore";

const app = initializeApp(firebaseConfig);
export const db = getFirestore(app);

export function createTask({ companyId, title, userId }) {
  return addDoc(collection(db, "companies", companyId, "tasks"), {
    title,
    status: "open",
    createdBy: userId,
    createdAt: serverTimestamp(),
  });
}

Brug servertid til felter, der skal sorteres eller auditeres. Lad Firestore generere dokument-ID'er, medmindre et stabilt domæne-ID som brugerens UID giver mening. Sekventielle ID'er kan skabe hotspots ved høj skriveaktivitet.

Security Rules skal følge datamodellen

Reglerne bør starte lukket og åbne adgang pr. collection. Eksemplet bruger et medlemsdokument til at kontrollere, om den indloggede bruger tilhører virksomheden. Det er stærkere end blot at kontrollere, om nogen er logget ind.

rules_version = "2";
service cloud.firestore {
  match /databases/{database}/documents {
    function isMember(companyId) {
      return request.auth != null
        && exists(/databases/$(database)/documents/
          companies/$(companyId)/members/$(request.auth.uid));
    }

    match /companies/{companyId}/tasks/{taskId} {
      allow read: if isMember(companyId);
      allow create: if isMember(companyId)
        && request.resource.data.createdBy == request.auth.uid;
      allow update: if isMember(companyId)
        && request.resource.data.createdBy == resource.data.createdBy;
      allow delete: if false;
    }

    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Eksemplet er et mønster, ikke en færdig regel til alle apps. Produktionsregler bør også validere tilladte felter, datatyper, statusovergange og roller. Test både tilladte og afviste operationer i Emulator Suite.

Indekser og forespørgsler

Firestore opretter automatiske enkeltfeltsindekser. Mere sammensatte forespørgsler kan kræve et composite index; SDK-fejlen giver normalt et link til at oprette det. Gem indeksdefinitionerne i firestore.indexes.json, så de følger koden og kan deployes ens i alle miljøer.

• Hent kun de dokumenter og felter, brugerflowet har brug for.
• Brug cursors frem for store offsets ved pagination.
• Fjern indeksering fra store tekst-, map- eller arrayfelter, som aldrig bruges i forespørgsler.
• Undgå realtidslisteners på brede collections, hvis skærmen kun behøver et lille udsnit.

Forbrug, backup og gendannelse

Firestore-forbrug afhænger blandt andet af dokumentlæsninger, skrivninger, sletninger, indekslæsninger, lagring og netværk. En lille kodefejl eller en listener, der genlæser for meget, kan derfor påvirke regningen.

• Budgetalarmer: Varsl ved lavere beløb end den grænse, der reelt vil gøre ondt.
• Usage dashboard: Følg ændringer efter releases og nye brugerflows.
• Backup: Vælg en plan, der matcher dataværdien, og dokumentér retention.
• Gendannelsestest: En backup er først troværdig, når I har prøvet at gendanne til et sikkert miljø.
• Sletning: Planlæg subcollections og persondata; et slettet parent-dokument rydder ikke automatisk underliggende data.

Typiske fejl før en Firebase-app går i drift

• Test Mode er stadig aktiv: Databasen har midlertidigt åbne regler.
• Appen deployes fra en lokal mappe: Ingen kan senere dokumentere præcis, hvilken commit der kom online.
• Dev og prod deler database: Tests ændrer eller sletter rigtige data.
• Hele collections lyttes til: Appen laver unødvendige læsninger og bliver dyrere med tiden.
• Datamodellen kopierer et UI: Den passer til første skærm, men ikke til regler, søgning eller fremtidige flows.
• Backup er lig med eksport: Der findes en fil, men ingen har dokumenteret eller testet gendannelsen.

Tjekliste før medarbejdere eller kunder får adgang

• □ Udvikling og produktion har separate Firebase-projekter og databaser.
• □ Firestore-regionen passer til brugere, backend og datakrav.
• □ Hosting deployer den rigtige buildmappe og har korrekte rewrites.
• □ Preview og smoke tests køres før produktionsdeployment.
• □ Datamodellen er dokumenteret med collections, ejerskab og centrale forespørgsler.
• □ Security Rules er lukket som udgangspunkt og testet for både tilladt og afvist adgang.
• □ Indekser og regler ligger i GitHub og deployes ensartet.
• □ Budgetalarmer, forbrugsovervågning og backup-retention er sat op.
• □ En gendannelse er prøvet i et ikke-produktionsmiljø.

Find den guide, der matcher projektet

Firebase er kun én mulig stack. Andre apps bruger eksempelvis Azure Functions, SQL eller eksterne API'er. Gå tilbage til guidebiblioteket, og vælg det emne, der svarer til den konkrete løsning frem for at følge en fast rækkefølge.