Firebase Realtime DB — vad är det, arkitektur och arbete med JSON

Vad är Firebase Realtime Database?

Firebase Realtime Database är en molnbaserad NoSQL-databas som lagrar och synkroniserar data i realtid mellan alla anslutna klienter. Lanserad 2012 som Firebase (innan förvärvet av Google) var den första molnbaserade realtidsdatabasen för mobila utvecklare. Data presenteras i JSON-format och organiseras i ett hierarkiskt träd där varje nod har en unik sökväg.

Huvudvärdet med Realtime Database är inbyggd synkronisering. När appen ändrar data på någon enhet får alla andra anslutna klienter omedelbart uppdateringen via en permanent anslutning. Detta besparar utvecklaren implementeringen av en egen synkroniseringsmekanism, WebSocket-server eller REST API för dataöverföring mellan klienter.

Databasen tillhandahåller SDK för alla större plattformar: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) och servermiljöer via Admin SDK. Enligt Google används Realtime Database i över 1,5 miljoner aktiva Firebase-projekt världen över. Trots tillkomsten av modernare Firestore förblir Realtime Database ett populärt val för projekt med enkel datastruktur.

Datastruktur: JSON-träd

Till skillnad från relationsdatabaser använder Realtime Database inte tabeller och rader. All data utgör ett enda JSON-träd som ser ut som nästlade JavaScript-objekt. Till exempel, för att lagra användare och deras meddelanden skapas en hierarki: users/userId/name och messages/messageId/text. Varje sökväg i trädet är en sträng och data kan läsas direkt via denna sökväg.

{
  "users": {
    "user1": {
      "name": "Ivan Petrov",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "Maria Sokolova",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "Hej!",
      "userId": "user1"
    }
  }
}

En viktig egenskap är att djup nästling påverkar prestandan. När appen läser data på en viss sökväg laddar den alla underordnade noder på den sökvägen. Därför rekommenderas att designa datastrukturen så platt som möjligt och undvika nästling djupare än 3–4 nivåer. För att kringgå detta problem används denormalisering av data — duplicering av information i olika noder i trädet.

Realtime Database vs Firestore: när välja

Realtime Database och Firestore jämförs ofta som två molnbaserade realtidsdatabaser från Google. Valet mellan dem beror på projektets specifika krav: frågekomplexitet, erforderlig konsistens och planerad belastning. Att förstå styrkorna hos varje databas hjälper till att fatta rätt arkitekturbeslut.

Den största fördelen med Realtime Database är låg synkroniseringsfördröjning. Eftersom all data lagras i ett enda JSON-träd utan ytterligare abstraktionslager är synkronisering snabbare än i Firestore. För applikationer där hastigheten på uppdateringsleverans är kritisk (chattar, onlinespel, system för gemensam redigering) kan Realtime Database vara ett lämpligare val.

När ska man använda Realtime Database

Realtime Database är mer lämpad för scenarier med enkel datastruktur och hög uppdateringsfrekvens. Typiska exempel: chattar, realtids-gillningar, skrivindikatorer, användares närvarostatus. Det är också ett bra val för prototyper och projekt med begränsad budget eftersom prissättningen baseras på datavolym, inte på antal operationer.

Å andra sidan, för applikationer med komplexa frågor (filtrering efter flera fält, sortering, aggregering) erbjuder Firestore mycket kraftfullare möjligheter. Realtime Database stöder endast filtrering efter en parameter och kan inte sortera resultat efter flera fält samtidigt. Om projektet planerar komplex dataanalys på klientsidan kommer Firestore att vara ett mer praktiskt val.

Hur fungerar synkronisering i Realtime Database

Realtime Database använder en permanent WebSocket-anslutning för tvåvägs datasynkronisering. När klienten anropar setValue eller updateChildren på en viss sökväg skickas data till Firebase-servern via en öppen kanal. Servern tillämpar ändringarna och sprider uppdateringarna till alla prenumererade klienter inom millisekunder. Varje anslutning identifieras av en unik sessionsnyckel.

Prenumerationsmekanismen fungerar via listeners. Utvecklaren kan prenumerera på ändring av en specifik nod (addListenerForSingleValueEvent) eller få permanenta uppdateringar (addValueEventListener). Vid varje dataändring anropas callback onDataChange med en fullständig ögonblicksbild av data på den angivna sökvägen. Detta skiljer sig från Firestore där endast ändrade dokument kommer — i Realtime Database laddas alltid alla data i noden.

Offlineläge och konflikthantering

Realtime Database stöder offlineläge på Android och iOS via diskcachelagring. SDK behåller en lokal kopia av data och fortsätter att bearbeta skrivoperationer vid frånvaro av nätverk. När anslutningen återställs skickas alla ackumulerade ändringar till servern. För att lösa konflikter används strategin last-write-wins, men utvecklaren kan implementera anpassad logik via ServerValue.TIMESTAMP för att lösa kollisioner.

val database = FirebaseDatabase.getInstance()
val myRef = database.getReference("messages")

// Skriva data
myRef.push().setValue(
    hashMapOf(
        "text" to "Nytt meddelande",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Läsning med konstant uppdatering
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "Data: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "Fel: ${error.message}")
    }
})

För optimering av trafik och prestanda rekommenderas att använda child listeners istället för value listeners när man behöver spåra ändringar av specifika underordnade noder. ChildEventListener tillhandahåller separata callbacks för att lägga till, ändra, ta bort och flytta underordnade element, vilket möjliggör mer exakt kontroll av UI-uppdateringar och förhindrar omritning av alla listelement vid varje dataändring.

Säkerhetsregler och datavalidering

Realtime Database använder ett deklarativt regelspråk för åtkomstkontroll till data. Reglerna beskriver vem som kan läsa och skriva data på varje sökväg i JSON-trädet. De kontrolleras på Firebase-servern inför varje begäran och kräver ingen serverlogik för auktorisering. Reglerna stöder variabler, inbyggda objekt och funktioner för flexibel åtkomstkonfiguration.

Som standard är åtkomst till databasen förbjuden för alla användare. Utvecklaren öppnar gradvis åtkomst med hjälp av regeln ".read" och ".write" på olika nivåer i trädet. Villkor kan kontrollera autentisering via variabeln auth, begärantyp (read/write) och befintlig data via objektet data. Dessutom stöder reglerna validering av skriven data via objektet newData.

{
  "rules": {
    "users": {
      "$uid": {
        // Endast ägaren kan läsa sina data
        ".read": "$uid === auth.uid",
        // Endast ägaren kan skriva
        ".write": "$uid === auth.uid",
        // Validering av fält vid skrivning
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Varje autentiserad kan läsa
      ".read": "auth !== null",
      // Endast autentiserad kan skriva
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

Reglerna stöder även indexering av data via direktivet ".indexOn". Utan detta kommer frågor med sortering (orderByChild) att avvisas eller utföras ineffektivt. Index anges för varje sökväg där sortering efter ett specifikt fält utförs. Reglerna är kaskadartade: djupare regler åsidosätter föräldrarregler, och om det på någon nivå inte finns någon åtkomst anses den vara tillåten eller förbjuden beroende på föräldrarregeln.

Datatyper och begränsningar

Realtime Database stöder fem datatyper: String, Number, Boolean, Map (objekt) och List (array). Nästlingsdjupet är begränsat till 32 nivåer och den maximala storleken på en nod får inte överskrida 256 MB. För effektivt arbete med databasen rekommenderas att designa en platt datastruktur och använda denormalisering för att undvika djupa frågor som laddar stora datavolymer.

Exempel på Realtime Database användning i Android

Låt oss titta på ett praktiskt exempel på integration av Realtime Database i en Android-app för användarstatus (online/offline). Appen kommer att visa en lista över användare med deras aktuella status, uppdaterad i realtid. För demonstrationen används Firebase Authentication för användaridentifikation och korutiner för asynkrona operationer.

Installation av beroenden och initialisering

Börja med att lägga till beroendet firebase-database-ktx i appmodulens build.gradle-fil. Biblioteksversionen hanteras via Firebase BoM för att säkerställa kompatibilitet för alla komponenter. Efter att ha lagt till beroendet måste Firebase initialiseras i Application-klassen eller via lat initialisering i ViewModel.

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-database-ktx"
    implementation "com.google.firebase:firebase-auth-ktx"
}

Efter konfiguration skapas ett repository för att arbeta med användare. Varje användare representeras av en nod i trädet /users/{uid} med fälten name, email och status. För att spåra status används onDisconnect — en speciell Firebase-mekanism som automatiskt utför en skrivoperation när klientanslutningen bryts. Detta garanterar att användarens status ändras till "offline" när appen stängs eller nätverket försvinner utan extra kod på klientsidan.

class PresenceRepository {
    private val database = FirebaseDatabase.getInstance()
    private val auth = FirebaseAuth.getInstance()
    private val presenceRef = database
        .getReference("presence")

    fun trackPresence() {
        val uid = auth.currentUser?.uid ?: return
        val userRef = presenceRef.child(uid)

        userRef.onDisconnect().setValue("offline")
        userRef.setValue("online")
    }

    fun getPresenceStream(): Flow<Map<String, String>> =
        presenceRef.snapshotFlow()
            .map { snapshot ->
                (snapshot.value as? Map<*, *>)
                    ?.mapKeys { it.key.toString() }
                    ?.mapValues { it.value.toString() }
                    ?: emptyMap()
            }
}

Nyckelelementet i exemplet är onDisconnect. Denna mekanism gör det möjligt att ställa in en skrivoperation som ska utföras på servern när klientanslutningen bryts. I detta fall, när användaren kopplas från, ställs dennes status automatiskt in på "offline" utan att behöva hantera appens stängningshändelse. Om appen avslutas oväntat kommer Firebase själv att utföra onDisconnect-operationen och andra användare kommer att se korrekt status.