Firebase Realtime Database: ce este, structura JSON și sincronizare

Ce este Firebase Realtime Database

Firebase Realtime Database este una dintre primele baze de date în cloud în timp real, lansată de Google împreună cu Firebase în 2012. Este o bază NoSQL unde datele sunt stocate ca un singur arbore JSON accesibil printr-un singur URL. SDK-urile client (Android, iOS, Web) se abonează la noduri specifice ale arborelui prin WebSocket și primesc actualizări la fiecare modificare a datelor — fără a face ping la server și fără a implementa propriul mecanism Push.

Istorie și dezvoltare

Firebase original a fost fondată în 2011 de James Tamplin și Andrew Lee, iar primul produs a fost exact Realtime Database. După achiziționarea de către Google în 2014 (conform TechCrunch — pentru o sumă între 50 și 100 de milioane de dolari), baza de date a fost integrată în Google Cloud și a primit o lățime de bandă semnificativ mai mare. În 2017, Google a anunțat Firestore ca înlocuitor evolutiv, dar Realtime Database continuă să fie activ suportată și actualizată. Conform datelor Google (2026), Realtime Database este încă utilizată în peste 1,5 milioane de proiecte active.

Limite gratuite și tarife

Tariful Spark (gratuit) include: 1 GB stocare, 10 GB date descărcate pe lună, 100 conexiuni simultane și suport pentru baza de date într-o singură regiune. În tariful Blaze (pay-as-you-go) se plătește pentru stocare suplimentară (1 $/GB), trafic (0,12 $/GB) și conexiuni simultane (5 $ pentru fiecare 100 de mii peste limită). Pentru testare este disponibil și modul de emulare — firebase emulators:start — care rulează Realtime Database local fără conexiune la cloud.

Structura datelor: arborele JSON și normalizarea

Realtime Database nu are tabele, colecții sau documente — totul este un singur arbore JSON accesibil la URL de forma https://project-name-default-rtdb.firebaseio.com/. Fiecare cheie a arborelui este fie o valoare finală (șir, număr, boolean, null), fie un nod imbricat cu chei copil. Motorul bazei de date nu suportă JOIN, subinterogări sau agregări — o interogare returnează întotdeauna conținutul unui singur nod cu toate elementele sale copil.

Normalizarea datelor

Din cauza absenței JOIN în Realtime Database, normalizarea datelor este obligatorie. În locul unui arbore imbricat (utilizator → lista postărilor sale), datele sunt împărțite în liste plate cu referințe prin chei. Aceasta este abordarea standard: datele sunt denormalizate astfel încât citirea unui nod să nu atragă întregul context. De exemplu, lista mesajelor de chat este stocată separat de profilurile utilizatorilor, iar fiecare postare conține doar ID-ul autorului, nu întregul său profil.

Interogări în Realtime Database

Interogările în Realtime Database se execută cu filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Spre deosebire de Firestore, indexurile se creează manual prin secțiunea Rules (.indexOn). Dacă indexul nu este declarat, interogarea cu sortare returnează eroarea PERMISSION_DENIED. Interogările funcționează doar pe un singur câmp — interogările compuse (filtru după preț + sortare după dată) nu sunt suportate. Pentru filtrarea complexă, datele sunt adesea duplicate în noduri diferite cu chei de sortare diferite.

Realtime Database vs Firestore: ce să alegi

Alegerea între Realtime Database și Firestore este una dintre deciziile arhitecturale frecvente la începutul unui proiect. Google recomandă Firestore pentru majoritatea aplicațiilor noi, dar Realtime Database rămâne cea mai bună alegere pentru scenarii unde latența minimă de transmitere a datelor este critică.

Trei scenarii cheie pentru Realtime Database

Primul scenariu — jocuri multiplayer cu sincronizare a stării (șah, jocuri de cărți, acțiune în timp real). Latența Realtime Database este de 10-30 ms față de 50-100 ms pentru Firestore în aceeași regiune. Al doilea scenariu — chat-uri și mesagerii cu frecvență ridicată a mesajelor. Realtime Database este tarifată după volumul de date, nu după numărul de scrieri, ceea ce o face semnificativ mai ieftină decât Firestore la o frecvență mai mare de 1 mesaj pe secundă. Al treilea scenariu — prezența (presence) utilizatorilor online/offline, unde handler-ele onDisconnect ale Realtime Database permit setarea atomică a stării la întreruperea conexiunii.

Conform datelor Google (2026), aproximativ 15% din noile proiecte Firebase aleg conștient Realtime Database — când echipa înțelege clar cerințele de latență, structura datelor și buget. În restul de 85% din cazuri, Firestore este alegerea mai sigură datorită scalabilității mai bune, interogărilor mai puternice și replicării automate.

Integrarea Realtime Database în Android

Conectarea Realtime Database la o aplicație Android se face prin adăugarea dependenței firebase-database-ktx în build.gradle. Obiectul FirebaseDatabase este disponibil prin getInstance(url) — se pot conecta mai multe baze de date în cadrul unui singur proiect Firebase. După inițializare, SDK stabilește automat conexiunea WebSocket cu serverul și începe sincronizarea datelor.

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

// Inițializare cu URL personalizat
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Scrierea și citirea datelor

Realtime Database folosește obiectul DatabaseReference pentru toate operațiile. setValue() scrie date în nodul specificat, înlocuind complet tot conținutul său. push() generează automat o cheie unică (pe baza timestamp-ului) pentru adăugarea unui element într-o listă — aceasta este metoda standard de creare a mesajelor de chat, postărilor și înregistrărilor. updateChildren() modifică mai multe noduri atomic într-o singură operație. addValueEventListener se abonează la modificările unui nod și primește un callback la fiecare actualizare a datelor.

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

Sincronizarea în timp real și modul offline

Mecanismul de sincronizare al Realtime Database se bazează pe protocolul WebSocket (anterior — long-polling). Clientul trimite o cerere de abonare la un nod specific, iar serverul menține conexiunea deschisă. La orice modificare a datelor în nodul abonat, serverul trimite clientului JSON-ul complet al acelui nod. SDK-ul pe partea clientului actualizează automat starea locală și apelează callback-urile corespunzătoare (onDataChange).

OnDisconnect — declanșatoare de deconectare

OnDisconnect — o capacitate unică a Realtime Database, absentă în Firestore. Dezvoltatorul poate înregistra o operație de scriere care se va executa automat pe server la întreruperea conexiunii clientului. Aceasta este folosită pentru stări de prezență: "user123/status": "online" cu onDisconnect.setValue("offline"). Dacă utilizatorul a închis aplicația sau a pierdut internetul, serverul va seta automat starea "offline" în cel mult 3 minute (configurabil în consola Firebase).

Cache offline

Persistence în Realtime Database se activează cu o singură linie: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK salvează în cache pe disc ultima stare a tuturor nodurilor abonate (implicit până la 10 MiB, configurabil până la 100 MiB). La pierderea conexiunii, clientul continuă să lucreze cu datele din cache, iar toate operațiile de scriere sunt puse în coadă. Când conexiunea se restabilește, SDK trimite toate modificările acumulate către server în ordinea corectă (FIFO).

Conform datelor Google (2026), aplicațiile cu cache persistence activat pierd datele utilizatorilor la întreruperea conexiunii cu 40% mai rar. Totuși, dacă clientul a acumulat peste 1000 de operații amânate, serverul poate respinge toate și solicita o sincronizare completă — acesta este un mecanism de protecție împotriva clienților învechiți.

Reguli de securitate și validare

Security Rules în Realtime Database este o configurație JSON care descrie cine și în ce condiții poate citi și scrie date în fiecare nod. Regulile funcționează pe serverul Google și se execută înaintea fiecărei operații. Implicit (în producție) se recomandă setarea regulilor în modul "închis" — doar utilizatorii autentificați au acces.

Structura rules

Regulile Realtime Database se scriu în format JSON cu secțiunile .read, .write, .validate, .indexOn. Spre deosebire de Firestore (care folosește sintaxa match), Realtime Database folosește obiecte imbricate care reflectă structura datelor. Condițiile verifică auth (autentificare), data (date existente), newData (date noi la scriere) și now (timpul serverului). Regulile de validare (.validate) permit verificarea tipurilor, intervalelor de valori și structurii datelor.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

Comportamentul în cascadă și testarea rules

Regulile Realtime Database se moștenesc în cascadă — dacă la nivelul superior .read = false, atunci toate nodurile copil sunt inaccesibile pentru citire indiferent de propriile lor reguli. Firebase oferă un simulator de reguli în consolă, unde se pot testa operațiile cu diferite token-uri auth înainte de implementare. Se recomandă întotdeauna testarea regulilor în simulator — o eroare într-o regulă poate deschide accesul la date private ale tuturor utilizatorilor. Conform datelor Google (2026), 40% din scurgerile de date în proiectele Firebase sunt cauzate de reguli de securitate configurate incorect.