Firebase Realtime DB — ce este, arhitectura și lucrul cu JSON

Ce este Firebase Realtime Database?

Firebase Realtime Database este o bază de date NoSQL în cloud care stochează și sincronizează date în timp real între toți clienții conectați. Lansată în 2012 ca Firebase (înainte de achiziția de către Google), a fost prima bază de date în timp real pentru dezvoltatorii mobili. Datele sunt prezentate în format JSON și organizate într-un arbore ierarhic, unde fiecare nod are o cale unică.

Valoarea principală a Realtime Database este sincronizarea integrată. Când aplicația modifică date pe orice dispozitiv, toți ceilalți clienți conectați primesc instantaneu actualizarea printr-o conexiune permanentă. Acest lucru scutește dezvoltatorul de implementarea propriului mecanism de sincronizare, server WebSocket sau REST API pentru transferul de date între clienți.

Baza de date oferă SDK pentru toate platformele principale: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) și medii server prin Admin SDK. Conform datelor Google, Realtime Database este utilizată în peste 1,5 milioane de proiecte active Firebase în întreaga lume. În ciuda apariției Firestore mai moderne, Realtime Database rămâne o alegere populară pentru proiecte cu structură simplă de date.

Structura datelor: arborele JSON

Spre deosebire de bazele de date relaționale, Realtime Database nu folosește tabele și rânduri. Toate datele constituie un singur arbore JSON care arată ca obiecte JavaScript imbricate. De exemplu, pentru stocarea utilizatorilor și mesajelor lor se creează o ierarhie: users/userId/name și messages/messageId/text. Fiecare cale în arbore este un șir și datele pot fi citite direct pe această cale.

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

O caracteristică importantă este că îmbricarea profundă afectează performanța. Când aplicația citește date pe o anumită cale, încarcă toate nodurile copil ale acelei căi. Prin urmare, se recomandă proiectarea structurii de date cât mai plate, evitând îmbricarea mai adâncă de 3–4 niveluri. Pentru a evita această problemă, se utilizează denormalizarea datelor — duplicarea informațiilor în diferite noduri ale arborelui.

Realtime Database vs Firestore: când să alegi

Realtime Database și Firestore sunt adesea comparate ca două baze de date în timp real de la Google. Alegerea între ele depinde de cerințele specifice ale proiectului: complexitatea interogărilor, consistența necesară și încărcarea planificată. Înțelegerea punctelor forte ale fiecărei baze ajută la luarea deciziei arhitecturale corecte.

Principalul avantaj al Realtime Database este latența redusă de sincronizare. Deoarece toate datele sunt stocate într-un singur arbore JSON fără straturi suplimentare de abstractizare, sincronizarea este mai rapidă decât în Firestore. Pentru aplicațiile unde viteza de livrare a actualizărilor este critică (chat-uri, jocuri online, sisteme de editare colaborativă), Realtime Database poate fi alegerea mai potrivită.

Când să utilizați Realtime Database

Realtime Database este mai potrivită pentru scenarii cu structură simplă de date și frecvență ridicată de actualizări. Exemple tipice: chat-uri, like-uri în timp real, indicatoare de tastare, stări de prezență a utilizatorilor. Este, de asemenea, o alegere bună pentru prototipuri și proiecte cu buget limitat, deoarece prețuirea se bazează pe volumul de date, nu pe numărul de operații.

Pe de altă parte, pentru aplicații cu interogări complexe (filtrare după mai multe câmpuri, sortare, agregare) Firestore oferă posibilități mult mai puternice. Realtime Database suportă doar filtrarea după un parametru și nu poate sorta rezultatele după mai multe câmpuri simultan. Dacă proiectul planifică o analitică complexă a datelor pe partea clientului, Firestore va fi alegerea mai practică.

Cum funcționează sincronizarea în Realtime Database

Realtime Database utilizează o conexiune WebSocket permanentă pentru sincronizarea bidirecțională a datelor. Când clientul apelează setValue sau updateChildren pe o anumită cale, datele sunt trimise la serverul Firebase printr-un canal deschis. Serverul aplică modificările și difuzează actualizările către toți clienții abonați în milisecunde. Fiecare conexiune este identificată printr-o cheie de sesiune unică.

Mecanismul de abonare funcționează prin listeneri. Dezvoltatorul se poate abona la modificarea unui anumit nod (addListenerForSingleValueEvent) sau poate primi actualizări permanente (addValueEventListener). La fiecare modificare a datelor, este apelat callback-ul onDataChange cu o imagine completă a datelor pe calea specificată. Acest lucru diferă de Firestore, unde vin doar documentele modificate — în Realtime Database se încarcă întotdeauna toate datele nodului.

Modul offline și gestionarea conflictelor

Realtime Database suportă modul offline pe Android și iOS prin cache pe disc. SDK păstrează o copie locală a datelor și continuă să proceseze operațiile de scriere în absența rețelei. Când conexiunea este restabilită, toate modificările acumulate sunt trimise la server. Pentru rezolvarea conflictelor se utilizează strategia last-write-wins, dar dezvoltatorul poate implementa o logică personalizată prin ServerValue.TIMESTAMP pentru rezolvarea coliziunilor.

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

// Scrierea datelor
myRef.push().setValue(
    hashMapOf(
        "text" to "Mesaj nou",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Citire cu actualizare permanentă
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "Date: $data")
    }

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

Pentru optimizarea traficului și performanței, se recomandă utilizarea child listeners în loc de value listeners atunci când trebuie urmărite modificările anumitor noduri copil. ChildEventListener oferă callback-uri separate pentru adăugarea, modificarea, ștergerea și mutarea elementelor copil, ceea ce permite un control mai precis al actualizărilor UI și evitarea redesenării tuturor elementelor listei la fiecare modificare a datelor.

Reguli de securitate și validarea datelor

Realtime Database utilizează un limbaj declarativ de reguli pentru controlul accesului la date. Regulile descriu cine poate citi și scrie date pe fiecare cale a arborelui JSON. Ele sunt verificate pe serverul Firebase înainte de fiecare cerere și nu necesită logică de server pentru autorizare. Regulile suportă variabile, obiecte încorporate și funcții pentru configurarea flexibilă a accesului.

Implicit, accesul la baza de date este interzis pentru toți utilizatorii. Dezvoltatorul deschide treptat accesul folosind regula ".read" și ".write" pe diferite niveluri ale arborelui. Condițiile pot verifica autentificarea prin variabila auth, tipul cererii (read/write) și datele existente prin obiectul data. În plus, regulile suportă validarea datelor scrise prin obiectul newData.

{
  "rules": {
    "users": {
      "$uid": {
        // Doar proprietarul poate citi datele sale
        ".read": "$uid === auth.uid",
        // Doar proprietarul poate scrie
        ".write": "$uid === auth.uid",
        // Validarea câmpurilor la scriere
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Orice utilizator autentificat poate citi
      ".read": "auth !== null",
      // Doar autentificat poate scrie
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

Regulile suportă, de asemenea, indexarea datelor prin directiva ".indexOn". Fără ea, interogările cu sortare (orderByChild) vor fi respinse sau executate ineficient. Indexurile sunt specificate pentru fiecare cale unde se efectuează sortarea după un anumit câmp. Regulile sunt în cascadă: regulile mai profunde le suprascriu pe cele părinte, iar dacă la un anumit nivel nu există acces, acesta este considerat permis sau interzis în funcție de regula părinte.

Tipuri de date și limitări

Realtime Database suportă cinci tipuri de date: String, Number, Boolean, Map (obiect) și List (matrice). Adâncimea de îmbricare este limitată la 32 de niveluri, iar dimensiunea maximă a unui nod nu trebuie să depășească 256 MB. Pentru o lucrare eficientă cu baza de date, se recomandă proiectarea unei structuri plate și utilizarea denormalizării pentru a evita interogările profunde care încarcă volume mari de date.

Exemplu de utilizare Realtime Database în Android

Să analizăm un exemplu practic de integrare a Realtime Database într-o aplicație Android pentru stări ale utilizatorilor (online/offline). Aplicația va afișa o listă de utilizatori cu starea lor curentă, actualizată în timp real. Pentru demonstrație se utilizează Firebase Authentication pentru identificarea utilizatorilor și corutine pentru operații asincrone.

Configurarea dependențelor și inițializarea

Pentru început, adăugați dependența firebase-database-ktx în fișierul build.gradle al modulului aplicației. Versiunea bibliotecii este gestionată prin Firebase BoM pentru a asigura compatibilitatea tuturor componentelor. După adăugarea dependenței, este necesară inițializarea Firebase în clasa Application sau prin inițializare întârziată în 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"
}

După configurare, se creează un repository pentru lucrul cu utilizatorii. Fiecare utilizator este reprezentat de un nod în arborele /users/{uid} cu câmpurile name, email și status. Pentru urmărirea stării se utilizează onDisconnect — un mecanism special Firebase care execută automat o operație de scriere la întreruperea conexiunii clientului. Aceasta garantează că starea utilizatorului se va schimba în "offline" la închiderea aplicației sau pierderea rețelei fără cod suplimentar pe partea clientului.

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()
            }
}

Elementul cheie al exemplului este onDisconnect. Acest mecanism permite setarea unei operații de scriere care va fi executată pe server la întreruperea conexiunii clientului. În acest caz, la deconectarea utilizatorului, starea sa este setată automat la "offline" fără a fi nevoie să gestionați evenimentul de închidere a aplicației. Dacă aplicația se termină neașteptat, Firebase va executa singur operația onDisconnect, iar ceilalți utilizatori vor vedea starea corectă.