Firebase Firestore: vad det är, NoSQL och hur det fungerar

Vad är Firebase Firestore?

Firebase Firestore är en flexibel, skalbar NoSQL-databas som lanserades av Google 2019 som en utveckling av Firebase Realtime Database. Den lagrar data i form av dokumentsamlingar, där varje dokument innehåller en uppsättning nyckel-värdepar. Till skillnad från traditionella relationsdatabaser kräver Firestore inget fördefinierat schema — datastrukturen formas dynamiskt baserat på de dokument som skrivs.

Den viktigaste skillnaden mellan Firestore och klassiska molndatabaser är den inbyggda realtidssynkroniseringen. När data ändras på servern får alla anslutna klienter uppdateringar via en permanent WebSocket-anslutning. Detta eliminerar behovet av manuell serveravfrågning och gör det möjligt att bygga applikationer med liveuppdateringar: chattar, aktivitetsflöden, samarbetsredigerare och övervakningssystem.

Databasen är tillgänglig på alla större plattformar: Android, iOS, Web (JavaScript) och serverspråk via Admin SDK. Firestore tillhandahåller SDK för Swift, Kotlin, JavaScript, Python, Go, Java och Node.js. Enligt Google bearbetar Firestore över 100 miljarder frågor per dag över hela Firebase-ekosystemet, vilket bekräftar dess tillförlitlighet som grund för produktionsapplikationer.

Grundläggande begrepp: samlingar och dokument

I Firestore är data organiserade i en hierarkisk struktur. En samling är en behållare för dokument, liknande en tabell i SQL, men utan fast schema. Ett dokument är en post som innehåller fält av olika typer: strängar, nummer, booleska värden, arrayer, nästlade objekt och geopunkter. Dokument kan innehålla undersamlingar, vilket gör det möjligt att bygga nästlade datastrukturer av valfritt djup.

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Anna Petrova",
    "email" to "anna@example.com",
    "age" to 28,
    "isActive" to true
)

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "Dokument tillagt med ID: ${docRef.id}")
    }

Varje dokument i en samling har en unik identifierare som kan genereras automatiskt eller ställas in manuellt. Firestore indexerar automatiskt alla fält i dokumentet, vilket möjliggör komplexa frågor med filtrering, sortering och begränsning av antalet resultat utan föregående indexkonfiguration.

Firebase Firestore vs Realtime Database: jämförelse

Firestore och Firebase Realtime Database är två molnbaserade realtidsdatabaser från Google. Även om båda tillhandahåller realtidssynkronisering har de grundläggande skillnader i datamodell, skalning och prissättning. Att förstå dessa skillnader är avgörande när man väljer rätt databas för ett specifikt projekt.

Den huvudsakliga arkitektoniska skillnaden är datamodellen. Realtime Database lagrar allt i ett enda stort JSON-träd, vilket försvårar frågor med djup nästling. Firestore använder samlingar och dokument, vilket möjliggör komplexa frågor med flera villkor. Dessutom ger Firestore stark datakonsistens: efter en lyckad skrivning returnerar alla efterföljande läsningar garanterat aktuella data.

Skalbarhet och datastruktur

Firestore skalar automatiskt upp till miljontals samtidiga anslutningar tack vare sin multi-regionala arkitektur. Realtime Database är begränsad till en region och maximalt 200.000 samtidiga anslutningar. För projekt som planerar en global publik är Firestore att föredra eftersom data automatiskt replikeras mellan flera Google-datacenter.

Datastrukturen i Firestore gör det möjligt att bygga komplexa hierarkiska modeller med undersamlingar. Till exempel kan en användare ha en undersamling "beställningar" och varje beställning en undersamling "produkter". I Realtime Database leder sådan djup nästling till prestandaproblem vid frågor, eftersom hela sökvägen från roten till den önskade noden laddas.

Hur datasynkronisering fungerar i Firestore

Firestore använder en permanent WebSocket-anslutning mellan klient och server för realtidsdatasynkronisering. När en app prenumererar på ändringar av ett dokument eller en samling via en snapshot-listener, upprättar SDK en kommunikationskanal genom vilken servern skickar uppdateringar vid varje dataändring. Klienten får endast de ändrade dokumenten, inte hela samlingen varje gång.

Synkroniseringsmekanismen är baserad på en händelseström: added (dokumentet dök upp), modified (dokumentet ändrades) och removed (dokumentet togs bort). Utvecklaren kan bearbeta varje händelse separat och endast uppdatera motsvarande UI-element. Detta säkerställer hög prestanda även med tusentals dokument, eftersom endast ändrade komponenter ritas om.

Offline-åtkomst och cachning

En av de viktigaste fördelarna med Firestore är det inbyggda stödet för offlineläge. SDK cachar automatiskt all läst data på enheten och fortsätter att fungera utan nätverk. När appen skriver data i offlineläge placeras de i en lokal kö och skickas till servern när anslutningen återställs. För att lösa konflikter används strategin last-write-wins.

val docRef = db.collection("cities").document("SF")

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "Lyssnarfel", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "Aktuella data: ${snapshot.data}")
    }
}

Cachestorleken kan konfigureras via FirestoreSettings. Som standard används 100 MB, men för applikationer med intensiv dataläsning kan den ökas. Det finns också ett persistent disk cache-läge som överlever omstart av appen. För att hantera tillgängligheten av offlineläge används metoderna enableNetwork och disableNetwork, som tillåter tillfällig avstängning av nätverkskommunikation.

Firestore-säkerhet och åtkomstregler

Firestore Security Rules är ett deklarativt märkningsspråk för att kontrollera dataåtkomst på servernivå. Reglerna bestämmer vem och under vilka förhållanden som kan läsa och skriva dokument. De fungerar före frågeexekvering och kräver ingen separat serverlogik för auktorisering. Reglerna kontrolleras på Firebase-sidan före varje läsning eller skrivning av data.

Åtkomstreglerna är uppbyggda enligt principen om tillåten åtkomst (allow). Som standard är all åtkomst förbjuden. Utvecklaren öppnar successivt åtkomst för specifika operationer (read, write, create, update, delete) under vissa villkor. Villkoren kan kontrollera användarautentisering via request.auth, frågedata via request.resource och befintlig data via resource.

// Firestore-åtkomstregler
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Användaren läser och skriver endast sin egen data
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // Varje autentiserad användare kan läsa inlägg
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

Datavalidering genom regler

Förutom åtkomstkontroll möjliggör Security Rules validering av strukturen och typerna på skriven data. Till exempel kan man kontrollera att e-postfältet matchar ett reguljärt uttryck eller att åldern inte överstiger 120 år. Validering utförs före skrivning, vilket förhindrar lagring av felaktig data på servern. För att kontrollera fält används objektet request.resource.data som innehåller hela dokumentet som ska skrivas.

Firestore stöder också samlingar som endast är tillgängliga för serverskrivning via Admin SDK, utan åtkomst från klientsidan. Detta är praktiskt för lagring av tjänsteinformation, API-nycklar och konfigurationer som inte bör vara synliga för användare. För detta räcker det i reglerna att förbjuda alla klientoperationer på motsvarande samlingar och endast tillåta åtkomst via Admin SDK på serversidan.

Exempel på Firebase Firestore i Android

Låt oss titta på ett exempel på integration av Firestore i en Android-app för att skapa en att-göra-lista (todo). Appen kommer att läsa uppgifter i realtid, lägga till nya och markera färdiga. För asynkront arbete används Firebase callback-gränssnitt och Kotlin-korutiner.

Konfigurera Firebase och lägga till beroenden

Innan du börjar måste du ansluta projektet till Firebase via Firebase Console och lägga till filen google-services.json i appmodulen. Sedan läggs beroendet firebase-firestore-ktx och google-services-plugin till i build.gradle. Biblioteksversionen måste motsvara den aktuella Firebase BoM-versionen för kompatibilitet mellan alla Firebase-komponenter.

dependencies {
    // Firebase BoM — versionshantering
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-firestore-ktx"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.9.0"
}

Efter konfiguration skapas datamodellen Task och ett arkiv för att arbeta med Firestore. Modellen innehåller fälten id, title, isCompleted och timestamp. Firestore serialiserar automatiskt data class till ett dokument med fältnamn som nycklar. För att läsa data används en snapshot-listener som returnerar en Flow via tillägget snapshotFlow.

data class Task(
    val id: String = "",
    val title: String = "",
    val isCompleted: Boolean = false,
    val createdAt: Timestamp? = null
)

class TaskRepository {
    private val tasksRef = FirebaseFirestore
        .getInstance()
        .collection("tasks")

    fun getTasks(): Flow<List<Task>> = tasksRef
        .orderBy("createdAt", Query.Direction.DESCENDING)
        .snapshotFlow()
        .map { snapshot ->
            snapshot?.toObjects(Task::class.java) ?: emptyList()
        }

    suspend fun addTask(title: String) {
        tasksRef.add(Task(title = title))
    }
}

View-modellen prenumererar på Flow från arkivet och skickar uppgiftslistan till UI-lagret. När en ny uppgift läggs till anropas arkivets suspend-funktion via korutin-scope. Firestore synkroniserar automatiskt ändringar mellan alla klienter: om en användare lägger till en uppgift ser andra den i realtid utan att skärmen laddas om.