Firebase Realtime Database: apa itu, struktur JSON dan sinkronisasi

Apa itu Firebase Realtime Database

Firebase Realtime Database adalah salah satu basis data cloud real-time pertama yang diluncurkan oleh Google bersama Firebase pada tahun 2012. Ini adalah basis data NoSQL di mana data disimpan sebagai satu pohon JSON yang dapat diakses melalui satu URL. SDK klien (Android, iOS, Web) berlangganan ke node tertentu dari pohon melalui WebSocket dan menerima pembaruan pada setiap perubahan data — tanpa melakukan ping ke server dan tanpa mengimplementasikan mekanisme Push sendiri.

Sejarah dan pengembangan

Firebase asli didirikan pada tahun 2011 oleh James Tamplin dan Andrew Lee, dan produk pertamanya adalah Realtime Database. Setelah diakuisisi oleh Google pada tahun 2014 (menurut TechCrunch — dengan nilai antara 50 hingga 100 juta dolar), basis data ini diintegrasikan ke dalam Google Cloud dan mendapatkan bandwidth yang jauh lebih tinggi. Pada tahun 2017, Google mengumumkan Firestore sebagai pengganti evolusioner, tetapi Realtime Database terus didukung dan diperbarui secara aktif. Menurut data Google (2026), Realtime Database masih digunakan di lebih dari 1,5 juta proyek aktif.

Batas gratis dan tarif

Tarif Spark (gratis) mencakup: 1 GB penyimpanan, 10 GB data yang diunduh per bulan, 100 koneksi simultan, dan dukungan basis data di satu wilayah. Pada tarif Blaze (pay-as-you-go), biaya dikenakan untuk penyimpanan tambahan ($1/GB), lalu lintas ($0,12/GB), dan koneksi simultan ($5 untuk setiap 100 ribu di atas batas). Untuk pengujian, mode emulasi juga tersedia — firebase emulators:start — yang menjalankan Realtime Database secara lokal tanpa koneksi ke cloud.

Struktur data: pohon JSON dan normalisasi

Realtime Database tidak memiliki tabel, koleksi, atau dokumen — semuanya adalah satu pohon JSON yang dapat diakses di URL seperti https://project-name-default-rtdb.firebaseio.com/. Setiap kunci pohon adalah nilai akhir (string, angka, boolean, null) atau node bersarang dengan kunci turunan. Mesin basis data tidak mendukung JOIN, subkueri, atau agregasi — kueri selalu mengembalikan konten satu node dengan semua elemen turunannya.

Normalisasi data

Karena tidak adanya JOIN di Realtime Database, normalisasi data adalah wajib. Alih-alih pohon bersarang (pengguna → daftar postingannya), data dibagi menjadi daftar datar dengan referensi melalui kunci. Ini adalah pendekatan standar: data didenormalisasi sehingga pembacaan satu node tidak menarik seluruh konteks. Misalnya, daftar pesan obrolan disimpan terpisah dari profil pengguna, dan setiap posting hanya berisi ID penulis, bukan seluruh profilnya.

Kueri di Realtime Database

Kueri di Realtime Database dijalankan dengan filter (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). Tidak seperti Firestore, indeks dibuat secara manual melalui bagian Rules (.indexOn). Jika indeks tidak dideklarasikan, kueri dengan pengurutan mengembalikan kesalahan PERMISSION_DENIED. Kueri hanya berfungsi pada satu bidang — kueri gabungan (filter berdasarkan harga + pengurutan berdasarkan tanggal) tidak didukung. Untuk pemfilteran yang kompleks, data sering diduplikasi di node yang berbeda dengan kunci pengurutan yang berbeda.

Realtime Database vs Firestore: mana yang dipilih

Pilihan antara Realtime Database dan Firestore adalah salah satu keputusan arsitektur yang sering muncul saat memulai proyek. Google merekomendasikan Firestore untuk sebagian besar aplikasi baru, tetapi Realtime Database tetap menjadi pilihan terbaik untuk skenario di mana latensi transmisi data yang minimal sangat penting.

Tiga skenario utama untuk Realtime Database

Skenario pertama — game multipemain dengan sinkronisasi status (catur, game kartu, aksi real-time). Latensi Realtime Database adalah 10-30 ms dibandingkan 50-100 ms untuk Firestore di wilayah yang sama. Skenario kedua — obrolan dan messenger dengan frekuensi pesan tinggi. Realtime Database ditagih berdasarkan volume data, bukan jumlah penulisan, membuatnya jauh lebih murah daripada Firestore pada frekuensi lebih dari 1 pesan per detik. Skenario ketiga — kehadiran (presence) pengguna online/offline, di mana penangan onDisconnect Realtime Database memungkinkan pengaturan status secara atomik saat koneksi terputus.

Menurut data Google (2026), sekitar 15% proyek Firebase baru secara sadar memilih Realtime Database — ketika tim memahami dengan jelas persyaratan latensi, struktur data, dan anggaran. Dalam 85% kasus lainnya, Firestore adalah pilihan yang lebih aman berkat skalabilitas yang lebih baik, kueri yang lebih kuat, dan replikasi otomatis.

Integrasi Realtime Database di Android

Menghubungkan Realtime Database ke aplikasi Android dilakukan dengan menambahkan dependensi firebase-database-ktx di build.gradle. Objek FirebaseDatabase tersedia melalui getInstance(url) — beberapa basis data dapat dihubungkan dalam satu proyek Firebase. Setelah inisialisasi, SDK secara otomatis membuat koneksi WebSocket dengan server dan memulai sinkronisasi data.

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

// Inisialisasi dengan URL khusus
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Menulis dan membaca data

Realtime Database menggunakan objek DatabaseReference untuk semua operasi. setValue() menulis data ke node yang ditentukan, sepenuhnya mengganti seluruh isinya. push() secara otomatis menghasilkan kunci unik (berdasarkan stempel waktu) untuk menambahkan elemen ke daftar — ini adalah cara standar untuk membuat pesan obrolan, posting, dan catatan. updateChildren() mengubah beberapa node secara atomik dalam satu operasi. addValueEventListener berlangganan perubahan node dan menerima callback pada setiap pembaruan data.

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

Sinkronisasi real-time dan mode offline

Mekanisme sinkronisasi Realtime Database didasarkan pada protokol WebSocket (sebelumnya — long-polling). Klien mengirimkan permintaan untuk berlangganan ke node tertentu, dan server menjaga koneksi tetap terbuka. Pada setiap perubahan data di node yang dilanggani, server mengirimkan JSON lengkap node tersebut ke klien. SDK di sisi klien secara otomatis memperbarui status lokal dan memanggil callback yang sesuai (onDataChange).

OnDisconnect — pemicu pemutusan

OnDisconnect — kemampuan unik Realtime Database yang tidak ada di Firestore. Pengembang dapat mendaftarkan operasi penulisan yang akan dijalankan secara otomatis di server saat koneksi klien terputus. Ini digunakan untuk status kehadiran: "user123/status": "online" dengan onDisconnect.setValue("offline"). Jika pengguna menutup aplikasi atau kehilangan internet, server akan secara otomatis mengatur status "offline" paling lambat dalam 3 menit (dapat dikonfigurasi di konsol Firebase).

Cache offline

Persistence di Realtime Database diaktifkan dengan satu baris: FirebaseDatabase.getInstance().setPersistenceEnabled(true). SDK menyimpan cache status terakhir semua node yang dilanggani di disk (secara default hingga 10 MiB, dapat dikonfigurasi hingga 100 MiB). Saat koneksi hilang, klien terus bekerja dengan data yang di-cache, dan semua operasi penulisan dimasukkan ke dalam antrian. Ketika koneksi dipulihkan, SDK mengirimkan semua perubahan yang terakumulasi ke server dalam urutan yang benar (FIFO).

Menurut data Google (2026), aplikasi dengan cache persistence yang diaktifkan 40% lebih jarang kehilangan data pengguna saat koneksi terputus. Namun, jika klien telah mengumpulkan lebih dari 1000 operasi yang ditangguhkan, server dapat menolak semuanya dan meminta sinkronisasi penuh — ini adalah mekanisme perlindungan terhadap klien yang usang.

Aturan keamanan dan validasi

Security Rules di Realtime Database adalah konfigurasi JSON yang menjelaskan siapa dan dalam kondisi apa dapat membaca dan menulis data di setiap node. Aturan bekerja di server Google dan dijalankan sebelum setiap operasi. Secara default (di produksi), disarankan untuk mengatur aturan dalam mode "tertutup" — hanya pengguna yang terautentikasi yang memiliki akses.

Struktur rules

Aturan Realtime Database ditulis dalam format JSON dengan bagian .read, .write, .validate, .indexOn. Tidak seperti Firestore (yang menggunakan sintaksis match), Realtime Database menggunakan objek bersarang yang mencerminkan struktur data. Kondisi memeriksa auth (otentikasi), data (data yang ada), newData (data baru saat penulisan), dan now (waktu server). Aturan validasi (.validate) memungkinkan pemeriksaan tipe, rentang nilai, dan struktur data.

{
  "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"
      }
    }
  }
}

Perilaku kaskade dan pengujian rules

Aturan Realtime Database diwariskan secara kaskade — jika di tingkat atas .read = false, maka semua node turunan tidak dapat diakses untuk dibaca terlepas dari aturan mereka sendiri. Firebase menyediakan simulator aturan di konsol di mana operasi dapat diuji dengan token auth yang berbeda sebelum diterapkan. Disarankan untuk selalu menguji aturan di simulator — kesalahan dalam aturan dapat membuka akses ke data pribadi semua pengguna. Menurut data Google (2026), 40% kebocoran data di proyek Firebase disebabkan oleh aturan keamanan yang dikonfigurasi secara tidak benar.