Firebase Realtime DB — ano ito, arkitektura at paggawa gamit ang JSON

Ano ang Firebase Realtime Database?

Firebase Realtime Database ay isang cloud NoSQL database na nag-iimbak at nag-sync ng data sa realtime sa pagitan ng lahat ng konektadong kliyente. Inilunsad noong 2012 bilang Firebase (bago ang pagkuha ng Google), ito ang naging unang cloud realtime database para sa mga mobile developer. Ang data ay ipinakita sa JSON format at naka-organisa sa isang hierarchical tree, kung saan ang bawat node ay may natatanging path.

Ang pangunahing halaga ng Realtime Database ay ang built-in na synchronization. Kapag binago ng app ang data sa anumang device, ang lahat ng iba pang konektadong kliyente ay agad na makakatanggap ng update sa pamamagitan ng permanenteng koneksyon. Ito ay nagliligtas sa developer mula sa pagpapatupad ng sariling synchronization mechanism, WebSocket server o REST API para sa paglipat ng data sa pagitan ng mga kliyente.

Ang database ay nagbibigay ng SDK para sa lahat ng pangunahing platform: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) at server environment sa pamamagitan ng Admin SDK. Ayon sa datos ng Google, ang Realtime Database ay ginagamit sa mahigit 1.5 milyong aktibong Firebase projects sa buong mundo. Sa kabila ng pagdating ng mas modernong Firestore, ang Realtime Database ay nananatiling popular na pagpili para sa mga project na may simpleng data structure.

Data structure: JSON tree

Hindi tulad ng relational databases, ang Realtime Database ay hindi gumagamit ng tables at rows. Lahat ng data ay bumubuo ng isang JSON tree na mukhang nested JavaScript objects. Halimbawa, para sa pag-iimbak ng mga user at kanilang mga mensahe, nilikha ang hierarchy: users/userId/name at messages/messageId/text. Bawat path sa tree ay isang string at ang data ay maaaring basahin nang direkta sa pamamagitan ng path na ito.

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

Isang mahalagang katangian ay ang malalim na nesting ay nakakaapekto sa performance. Kapag binabasa ng app ang data sa isang partikular na path, nilo-load nito ang lahat ng child nodes ng path na iyon. Kaya inirerekomenda na idisenyo ang data structure na flat hangga't maaari, iwasan ang nesting na mas malalim sa 3–4 na level. Upang malutas ang problemang ito, ginagamit ang denormalization ng data — pag-duplicate ng impormasyon sa iba't ibang nodes ng tree.

Realtime Database vs Firestore: kailan pumili

Realtime Database at Firestore ay madalas na inihambing bilang dalawang cloud realtime databases mula sa Google. Ang pagpili sa pagitan ng mga ito ay depende sa mga partikular na pangangailangan ng project: pagiging kumplikado ng queries, kinakailangang consistency at planadong load. Ang pag-unawa sa mga kalakasan ng bawat database ay tumutulong sa paggawa ng tamang desisyon sa arkitektura.

Ang pangunahing bentahe ng Realtime Database ay mababang synchronization latency. Dahil ang lahat ng data ay naka-imbak sa isang JSON tree na walang karagdagang abstraction layers, ang synchronization ay mas mabilis kaysa sa Firestore. Para sa mga application kung saan ang bilis ng paghahatid ng mga update ay kritikal (chats, online games, collaborative editing systems), ang Realtime Database ay maaaring maging mas angkop na pagpili.

Kailan gagamitin ang Realtime Database

Realtime Database ay mas angkop para sa mga scenario na may simpleng data structure at mataas na dalas ng pag-update. Mga tipikal na halimbawa: chats, realtime likes, typing indicators, user presence status. Ito rin ay magandang pagpili para sa mga prototype at project na may limitadong budget, dahil ang pagpepresyo ay batay sa dami ng data, hindi sa bilang ng operations.

Sa kabilang banda, para sa mga application na may kumplikadong queries (filtering sa maraming fields, sorting, aggregation) Firestore ay nag-aalok ng mas malakas na kakayahan. Ang Realtime Database ay sumusuporta lamang ng filtering sa isang parameter at hindi kayang mag-sort ng results sa maraming fields nang sabay-sabay. Kung ang project ay nagpaplano ng kumplikadong data analytics sa client side, ang Firestore ay magiging mas praktikal na pagpili.

Paano gumagana ang synchronization sa Realtime Database

Realtime Database ay gumagamit ng permanenteng WebSocket connection para sa bidirectional data synchronization. Kapag ang client ay tumawag ng setValue o updateChildren sa isang partikular na path, ang data ay ipinapadala sa Firebase server sa pamamagitan ng bukas na channel. Ang server ay nag-aplay ng mga pagbabago at nag-broadcast ng mga update sa lahat ng naka-subscribe na kliyente sa loob ng millisecond. Bawat koneksyon ay kinikilala ng natatanging session key.

Ang mekanismo ng subscription ay gumagana sa pamamagitan ng listeners. Ang developer ay maaaring mag-subscribe sa pagbabago ng isang partikular na node (addListenerForSingleValueEvent) o makatanggap ng permanenteng updates (addValueEventListener). Sa bawat pagbabago ng data, ang callback na onDataChange ay tinatawag na may kumpletong snapshot ng data sa tinukoy na path. Ito ay naiiba sa Firestore, kung saan ang mga binagong dokumento lamang ang dumarating — sa Realtime Database, lahat ng data ng node ay palaging nalo-load.

Offline mode at pamamahala ng conflict

Realtime Database ay sumusuporta sa offline mode sa Android at iOS sa pamamagitan ng disk caching. Ang SDK ay nag-iimbak ng lokal na kopya ng data at patuloy na nagpro-process ng write operations kapag walang network. Kapag naibalik ang koneksyon, lahat ng naipon na pagbabago ay ipinadala sa server. Para sa paglutas ng conflicts, ginagamit ang last-write-wins strategy, ngunit ang developer ay maaaring magpatupad ng custom na logic sa pamamagitan ng ServerValue.TIMESTAMP para sa paglutas ng collisions.

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

// Pagsusulat ng data
myRef.push().setValue(
    hashMapOf(
        "text" to "Bagong mensahe",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Pagbasa na may patuloy na update
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", "Error: ${error.message}")
    }
})

Para sa pag-optimize ng traffic at performance, inirerekomenda ang paggamit ng child listeners sa halip na value listeners kapag kailangang subaybayan ang mga pagbabago ng partikular na child nodes. Ang ChildEventListener ay nagbibigay ng hiwalay na callbacks para sa pagdaragdag, pagbabago, pagtanggal at paglipat ng mga child elements, na nagbibigay-daan sa mas tumpak na kontrol ng UI updates at pag-iwas sa pag-render muli ng lahat ng list elements sa bawat pagbabago ng data.

Mga Security Rules at Data Validation

Realtime Database ay gumagamit ng declarative rule language para sa data access control. Ang rules ay naglalarawan kung sino ang maaaring magbasa at magsulat ng data sa bawat path ng JSON tree. Ang mga ito ay sinusuri sa Firebase server bago ang bawat request at hindi nangangailangan ng server logic para sa authorization. Ang rules ay sumusuporta sa variables, built-in objects at functions para sa flexible access configuration.

Bilang default, ang access sa database ay ipinagbabawal para sa lahat ng user. Ang developer ay unti-unting nagbubukas ng access gamit ang rule na ".read" at ".write" sa iba't ibang antas ng tree. Ang conditions ay maaaring suriin ang authentication sa pamamagitan ng auth variable, request type (read/write) at umiiral na data sa pamamagitan ng data object. Bukod pa rito, ang rules ay sumusuporta sa validation ng isinulat na data sa pamamagitan ng newData object.

{
  "rules": {
    "users": {
      "$uid": {
        // Tanging may-ari ang makakabasa ng sariling data
        ".read": "$uid === auth.uid",
        // Tanging may-ari ang makakasulat
        ".write": "$uid === auth.uid",
        // Validation ng fields sa pagsusulat
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Sinumang naka-authenticate ay makakabasa
      ".read": "auth !== null",
      // Tanging naka-authenticate ang makakasulat
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

Ang rules ay sumusuporta rin sa pag-index ng data sa pamamagitan ng directive na ".indexOn". Kung wala ito, ang queries na may sorting (orderByChild) ay tatanggihan o isasagawa nang hindi mahusay. Ang indexes ay tinukoy para sa bawat path kung saan ginagawa ang sorting batay sa isang partikular na field. Ang rules ay cascading: ang mas malalim na rules ay nag-o-override sa parent rules, at kung sa isang antas ay walang access, ito ay itinuturing na pinapayagan o ipinagbabawal depende sa parent rule.

Mga uri ng data at limitasyon

Realtime Database ay sumusuporta sa limang uri ng data: String, Number, Boolean, Map (object) at List (array). Ang lalim ng nesting ay limitado sa 32 na antas at ang maximum na laki ng isang node ay hindi dapat lumagpas sa 256 MB. Para sa mahusay na pagtatrabaho sa database, inirerekomenda ang pagdisenyo ng flat data structure at paggamit ng denormalization upang maiwasan ang malalim na queries na naglo-load ng malalaking volume ng data.

Halimbawa ng paggamit ng Realtime Database sa Android

Tingnan natin ang praktikal na halimbawa ng integrasyon ng Realtime Database sa Android app para sa mga user status (online/offline). Ang app ay magpapakita ng listahan ng mga user na may kanilang kasalukuyang status, na nai-update sa realtime. Para sa demonstrasyon, ginagamit ang Firebase Authentication para sa pagkilala ng user at coroutines para sa asynchronous operations.

Pag-setup ng dependencies at initialization

Para magsimula, idagdag ang dependency na firebase-database-ktx sa build.gradle file ng app module. Ang bersyon ng library ay pinamamahalaan sa pamamagitan ng Firebase BoM upang matiyak ang compatibility ng lahat ng components. Pagkatapos idagdag ang dependency, kailangang i-initialize ang Firebase sa Application class o sa pamamagitan ng lazy initialization sa 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"
}

Pagkatapos ng configuration, nilikha ang repository para sa pagtatrabaho sa mga user. Bawat user ay kinakatawan ng isang node sa /users/{uid} tree na may fields na name, email at status. Para sa pagsubaybay ng status, ginagamit ang onDisconnect — isang espesyal na mekanismo ng Firebase na awtomatikong nagsasagawa ng write operation kapag naputol ang koneksyon ng client. Tinitiyak nito na ang status ng user ay magbabago sa "offline" kapag isinara ang app o nawala ang network nang walang karagdagang code sa client side.

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

Ang pangunahing elemento ng halimbawa ay ang onDisconnect. Ang mekanismong ito ay nagbibigay-daan sa pag-set ng write operation na isasagawa sa server kapag naputol ang koneksyon ng client. Sa kasong ito, kapag nadiskonekta ang user, ang kanyang status ay awtomatikong naka-set sa "offline" nang hindi kinakailangang pangasiwaan ang event ng pagsasara ng app. Kung ang app ay biglang magsara, ang Firebase mismo ang magsasagawa ng onDisconnect operation at ang ibang mga user ay makakakita ng tamang status.