Firebase Firestore: ano ito, NoSQL at paano ito gumagana

Ano ang Firebase Firestore?

Firebase Firestore ay isang flexible, scalable na NoSQL database na inilunsad ng Google noong 2019 bilang ebolusyon ng Firebase Realtime Database. Nag-iimbak ito ng data sa anyo ng mga koleksyon ng dokumento, kung saan ang bawat dokumento ay naglalaman ng isang set ng key-value pairs. Hindi tulad ng tradisyonal na relational database, ang Firestore ay hindi nangangailangan ng paunang natukoy na schema — ang istraktura ng data ay dynamic na nabubuo batay sa mga dokumentong isinulat.

Ang pangunahing pagkakaiba ng Firestore mula sa mga klasikong cloud database ay ang built-in na real-time na pag-sync. Kapag nagbago ang data sa server, lahat ng konektadong kliyente ay makakatanggap ng mga update sa pamamagitan ng permanenteng WebSocket na koneksyon. Tinatanggal nito ang pangangailangan para sa manual na pag-poll sa server at pinapayagan ang pagbuo ng mga application na may live na update: mga chat, activity feed, collaborative editor, at monitoring system.

Ang database ay available sa lahat ng pangunahing platform: Android, iOS, Web (JavaScript) at mga server language sa pamamagitan ng Admin SDK. Nagbibigay ang Firestore ng SDK para sa Swift, Kotlin, JavaScript, Python, Go, Java at Node.js. Ayon sa data ng Google, ang Firestore ay nagpoproseso ng higit sa 100 bilyong query bawat araw sa buong Firebase ecosystem, na nagpapatunay ng pagiging maaasahan nito bilang batayan para sa production application.

Mga pangunahing konsepto: mga koleksyon at dokumento

Sa Firestore, ang data ay nakaayos sa isang hierarchical na istraktura. Ang koleksyon ay isang lalagyan ng mga dokumento, katulad ng isang table sa SQL, ngunit walang fixed schema. Ang dokumento ay isang record na naglalaman ng mga field ng iba't ibang uri: mga string, numero, boolean value, array, nested object, at geo-point. Ang mga dokumento ay maaaring maglaman ng mga subcollection, na nagpapahintulot sa pagbuo ng nested data structure ng anumang lalim.

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Anna Petrova",
    "email" to "anna@example.com",
    "age" to 28,
    "isActive" to true
)

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "Dokumento naidagdag na may ID: ${docRef.id}")
    }

Ang bawat dokumento sa isang koleksyon ay may natatanging identifier na maaaring awtomatikong mabuo o manu-manong itakda. Awtomatikong ini-index ng Firestore ang lahat ng field ng dokumento, na nagpapahintulot sa pagpapatupad ng mga kumplikadong query na may filtering, sorting, at paglilimita ng bilang ng mga resulta nang walang paunang configuration ng index.

Firebase Firestore vs Realtime Database: paghahambing

Firestore at Firebase Realtime Database ay dalawang cloud real-time na database mula sa Google. Kahit na pareho silang nagbibigay ng real-time na pag-sync, mayroon silang pangunahing pagkakaiba sa modelo ng data, scalability, at pagpepresyo. Ang pag-unawa sa mga pagkakaibang ito ay kritikal kapag pumipili ng tamang database para sa isang partikular na proyekto.

Ang pangunahing pagkakaiba sa arkitektura ay ang modelo ng data. Ang Realtime Database ay nag-iimbak ng lahat sa isang malaking JSON tree, na nagpapahirap sa mga query na may malalim na nesting. Firestore ay gumagamit ng mga koleksyon at dokumento, na nagpapahintulot sa pagpapatupad ng mga kumplikadong query na may maraming kondisyon. Bukod pa rito, tinitiyak ng Firestore ang malakas na consistency ng data: pagkatapos ng matagumpay na pagsulat, ang lahat ng kasunod na pagbasa ay garantisadong nagbabalik ng kasalukuyang data.

Scalability at istraktura ng data

Firestore ay awtomatikong nag-scale hanggang milyong sabay-sabay na koneksyon salamat sa multi-regional na arkitektura. Ang Realtime Database ay limitado sa isang rehiyon at maximum na 200,000 sabay-sabay na koneksyon. Para sa mga proyektong nagpaplano ng pandaigdigang audience, mas gusto ang Firestore dahil ang data ay awtomatikong nare-replicate sa pagitan ng maraming data center ng Google.

Ang istraktura ng data sa Firestore ay nagpapahintulot sa pagbuo ng mga kumplikadong hierarchical na modelo na may mga subcollection. Halimbawa, ang isang user ay maaaring magkaroon ng subcollection na "mga order", at bawat order ay may subcollection na "mga produkto". Sa Realtime Database, ang ganitong malalim na nesting ay humahantong sa mga problema sa pagganap sa mga query, dahil ang buong path mula sa root hanggang sa nais na node ay nai-load.

Paano gumagana ang pag-sync ng data sa Firestore

Firestore ay gumagamit ng permanenteng WebSocket na koneksyon sa pagitan ng kliyente at server para sa real-time na pag-sync ng data. Kapag ang isang app ay nag-subscribe sa mga pagbabago ng isang dokumento o koleksyon sa pamamagitan ng snapshot listener, ang SDK ay nagtatatag ng isang channel ng komunikasyon kung saan ang server ay nagpapadala ng mga update sa bawat pagbabago ng data. Ang kliyente ay tumatanggap lamang ng mga binagong dokumento, hindi ang buong koleksyon sa bawat pagkakataon.

Ang mekanismo ng pag-sync ay batay sa stream ng mga event: added (lumitaw ang dokumento), modified (nagbago ang dokumento), at removed (tinanggal ang dokumento). Ang developer ay maaaring mag-proseso ng bawat event nang hiwalay, nag-a-update lamang ng mga kaukulang elemento ng UI. Tinitiyak nito ang mataas na pagganap kahit na may libu-libong dokumento, dahil ang mga nabagong component lamang ang muling iginuguhit.

Offline na access at caching

Isa sa mga pangunahing bentahe ng Firestore ay ang built-in na suporta para sa offline mode. Awtomatikong nag-cache ang SDK ng lahat ng nabasang data sa device at patuloy na gumagana kahit walang network. Kapag ang app ay nagsusulat ng data sa offline mode, ang mga ito ay inilalagay sa isang lokal na pila at ipinapadala sa server kapag naibalik ang koneksyon. Para sa paglutas ng mga conflict, ginagamit ang last-write-wins na strategy.

val docRef = db.collection("cities").document("SF")

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "Error sa pakikinig", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "Kasalukuyang data: ${snapshot.data}")
    }
}

Ang laki ng cache ay maaaring i-configure sa pamamagitan ng FirestoreSettings. Bilang default, ginagamit ang 100 MB, ngunit para sa mga app na may intensive na pagbabasa ng data, maaari itong dagdagan. Mayroon ding persistent disk cache mode na nananatili pagkatapos ng pag-restart ng app. Para sa pamamahala ng availability ng offline mode, ginagamit ang mga enableNetwork at disableNetwork na pamamaraan, na nagpapahintulot sa pansamantalang pag-disable ng network communication.

Seguridad at mga panuntunan sa pag-access ng Firestore

Firestore Security Rules ay isang declarative markup language para sa pagkontrol ng access sa data sa antas ng server. Tinutukoy ng mga panuntunan kung sino at sa ilalim ng anong mga kondisyon ang maaaring magbasa at magsulat ng mga dokumento. Gumagana ang mga ito bago ang pagpapatupad ng query at hindi nangangailangan ng hiwalay na server logic para sa awtorisasyon. Ang mga panuntunan ay sinusuri sa bahagi ng Firebase bago ang bawat pagbasa o pagsulat ng data.

Ang mga panuntunan sa pag-access ay binuo sa prinsipyo ng pinapayagang access (allow). Bilang default, lahat ng access ay ipinagbabawal. Ang developer ay sunod-sunod na nagbubukas ng access para sa mga tiyak na operasyon (read, write, create, update, delete) sa ilalim ng ilang mga kondisyon. Ang mga kondisyon ay maaaring suriin ang authentication ng user sa pamamagitan ng request.auth, data ng query sa pamamagitan ng request.resource, at umiiral na data sa pamamagitan ng resource.

// Mga panuntunan sa pag-access ng Firestore
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Ang user ay nagbabasa at nagsusulat lamang ng sariling data
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // Sinumang napatotohanang user ay maaaring magbasa ng mga post
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

Pag-validate ng data sa pamamagitan ng mga panuntunan

Bukod sa pagkontrol ng access, pinapayagan ng Security Rules ang pag-validate ng istraktura at mga uri ng isinulat na data. Halimbawa, maaaring suriin kung ang email field ay tumutugma sa isang regular expression, o kung ang edad ay hindi lalampas sa 120 taon. Ang pag-validate ay ginagawa bago ang pagsulat, na pumipigil sa pag-imbak ng maling data sa server. Para sa pagsusuri ng mga field, ginagamit ang request.resource.data na object na naglalaman ng buong dokumento na isinusulat.

Sinusuportahan din ng Firestore ang mga koleksyon na available lamang para sa server write sa pamamagitan ng Admin SDK, nang walang access mula sa mga kliyente. Ito ay maginhawa para sa pag-iimbak ng service information, API keys, at configuration na hindi dapat makita ng mga user. Para dito, sapat na sa mga panuntunan na ipagbawal ang lahat ng client operations sa mga kaukulang koleksyon, na nagpapahintulot lamang ng access sa pamamagitan ng Admin SDK sa bahagi ng server.

Halimbawa ng paggamit ng Firebase Firestore sa Android

Tingnan natin ang isang halimbawa ng pagsasama ng Firestore sa isang Android app para sa paggawa ng listahan ng mga gawain (todo). Ang app ay magbabasa ng mga gawain sa real-time, magdagdag ng bago, at markahan ang mga natapos. Para sa asynchronous na trabaho, ginagamit ang Firebase callback interface at Kotlin coroutine.

Pag-configure ng Firebase at pagdaragdag ng mga dependency

Bago magsimula, kailangang ikonekta ang proyekto sa Firebase sa pamamagitan ng Firebase Console at idagdag ang google-services.json file sa module ng app. Pagkatapos, sa build.gradle ay idinaragdag ang dependency na firebase-firestore-ktx at ang google-services plugin. Ang bersyon ng library ay dapat tumugma sa kasalukuyang bersyon ng Firebase BoM para sa compatibility ng lahat ng Firebase component.

dependencies {
    // Firebase BoM — pamamahala ng bersyon
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-firestore-ktx"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.9.0"
}

Pagkatapos ng configuration, ginagawa ang data model na Task at repository para sa pagtatrabaho sa Firestore. Ang modelo ay naglalaman ng mga field na id, title, isCompleted, at timestamp. Awtomatikong sine-serialize ng Firestore ang data class sa isang dokumento, gamit ang mga pangalan ng field bilang mga key. Para sa pagbabasa ng data, ginagamit ang snapshot listener na nagbabalik ng Flow sa pamamagitan ng extension na snapshotFlow.

data class Task(
    val id: String = "",
    val title: String = "",
    val isCompleted: Boolean = false,
    val createdAt: Timestamp? = null
)

class TaskRepository {
    private val tasksRef = FirebaseFirestore
        .getInstance()
        .collection("tasks")

    fun getTasks(): Flow<List<Task>> = tasksRef
        .orderBy("createdAt", Query.Direction.DESCENDING)
        .snapshotFlow()
        .map { snapshot ->
            snapshot?.toObjects(Task::class.java) ?: emptyList()
        }

    suspend fun addTask(title: String) {
        tasksRef.add(Task(title = title))
    }
}

Ang view-model ay nag-subscribe sa Flow mula sa repository at nagpapasa ng listahan ng mga gawain sa UI layer. Kapag nagdadagdag ng bagong gawain, ang suspend-function ng repository ay tinatawag sa pamamagitan ng coroutine scope. Awtomatikong nagsi-sync ang Firestore ng mga pagbabago sa pagitan ng lahat ng kliyente: kung ang isang user ay nagdagdag ng gawain, makikita ito ng iba sa real-time nang hindi nire-reload ang screen.