Firebase Firestore: co to jest, NoSQL i jak działa

Czym jest Firebase Firestore?

Firebase Firestore to elastyczna, skalowalna baza danych NoSQL, uruchomiona przez Google w 2019 roku jako ewolucja Firebase Realtime Database. Przechowuje dane w postaci kolekcji dokumentów, gdzie każdy dokument zawiera zestaw par klucz-wartość. W przeciwieństwie do tradycyjnych relacyjnych baz danych, Firestore nie wymaga wcześniej zdefiniowanego schematu — struktura danych tworzona jest dynamicznie na podstawie zapisywanych dokumentów.

Kluczowa różnica Firestore w porównaniu do klasycznych baz chmurowych to wbudowana synchronizacja czasu rzeczywistego. Gdy dane zmieniają się na serwerze, wszyscy podłączeni klienci otrzymują aktualizacje przez stałe połączenie WebSocket. Eliminuje to konieczność ręcznego odpytywania serwera i pozwala budować aplikacje z żywymi aktualizacjami: czaty, kanały aktywności, edytory współdzielone i systemy monitorowania.

Baza danych jest dostępna na wszystkich głównych platformach: Android, iOS, Web (JavaScript) i językach serwerowych przez Admin SDK. Firestore udostępnia SDK dla Swift, Kotlin, JavaScript, Python, Go, Java i Node.js. Według danych Google, Firestore przetwarza ponad 100 miliardów zapytań dziennie w całym ekosystemie Firebase, co potwierdza jej niezawodność jako podstawy dla aplikacji produkcyjnych.

Podstawowe pojęcia: kolekcje i dokumenty

W Firestore dane są zorganizowane w hierarchiczną strukturę. Kolekcja to kontener dokumentów, podobny do tabeli w SQL, ale bez stałego schematu. Dokument to rekord zawierający pola różnych typów: ciągi znaków, liczby, wartości logiczne, tablice, zagnieżdżone obiekty i geopunkty. Dokumenty mogą zawierać podkolekcje, co pozwala budować zagnieżdżone struktury danych o dowolnej głębokości.

val db = FirebaseFirestore.getInstance()

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

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "Dokument dodany z ID: ${docRef.id}")
    }

Każdy dokument w kolekcji ma unikalny identyfikator, który może być generowany automatycznie lub ustawiony ręcznie. Firestore automatycznie indeksuje wszystkie pola dokumentu, co umożliwia wykonywanie złożonych zapytań z filtrowaniem, sortowaniem i ograniczaniem liczby wyników bez wcześniejszej konfiguracji indeksów.

Firebase Firestore vs Realtime Database: porównanie

Firestore i Firebase Realtime Database to dwie chmurowe bazy danych czasu rzeczywistego od Google. Chociaż obie zapewniają synchronizację w czasie rzeczywistym, mają zasadnicze różnice w modelu danych, skalowaniu i cenach. Zrozumienie tych różnic jest kluczowe przy wyborze odpowiedniej bazy dla konkretnego projektu.

Podstawowa różnica architektoniczna to model danych. Realtime Database przechowuje wszystko w jednym dużym drzewie JSON, co utrudnia zapytania z głębokim zagnieżdżeniem. Firestore używa kolekcji i dokumentów, co umożliwia wykonywanie złożonych zapytań z wieloma warunkami. Ponadto Firestore zapewnia silną spójność danych: po pomyślnym zapisie wszystkie kolejne odczyty gwarantują zwrócenie aktualnych danych.

Skalowalność i struktura danych

Firestore skaluje się automatycznie do milionów jednoczesnych połączeń dzięki architekturze wieloregionalnej. Realtime Database jest ograniczona do jednego regionu i maksymalnie 200 000 jednoczesnych połączeń. Dla projektów planujących globalną publiczność Firestore jest preferowany, ponieważ dane są automatycznie replikowane między wieloma centrami danych Google.

Struktura danych w Firestore pozwala budować złożone modele hierarchiczne z podkolekcjami. Na przykład użytkownik może mieć podkolekcję „zamówienia", a każde zamówienie — podkolekcję „produkty". W Realtime Database takie głębokie zagnieżdżenie prowadzi do problemów z wydajnością przy zapytaniach, ponieważ ładowana jest cała ścieżka od korzenia do żądanego węzła.

Jak działa synchronizacja danych w Firestore

Firestore używa stałego połączenia WebSocket między klientem a serwerem do synchronizacji danych w czasie rzeczywistym. Gdy aplikacja subskrybuje zmiany dokumentu lub kolekcji przez snapshot listener, SDK ustanawia kanał komunikacji, przez który serwer wysyła aktualizacje przy każdej zmianie danych. Klient otrzymuje tylko zmienione dokumenty, a nie pełny zrzut całej kolekcji za każdym razem.

Mechanizm synchronizacji opiera się na strumieniu zdarzeń: added (dokument pojawił się), modified (dokument zmienił się) i removed (dokument został usunięty). Deweloper może przetwarzać każde zdarzenie osobno, aktualizując tylko odpowiednie elementy interfejsu. Zapewnia to wysoką wydajność nawet przy tysiącach dokumentów, ponieważ przerysowywane są tylko zmienione komponenty.

Dostęp offline i buforowanie

Jedna z kluczowych zalet Firestore to wbudowana obsługa trybu offline. SDK automatycznie buforuje wszystkie odczytane dane na urządzeniu i kontynuuje działanie przy braku sieci. Gdy aplikacja zapisuje dane w trybie offline, są one umieszczane w lokalnej kolejce i wysyłane na serwer po przywróceniu połączenia. Do rozwiązywania konfliktów używana jest strategia last-write-wins.

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

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "Błąd nasłuchiwania", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "Bieżące dane: ${snapshot.data}")
    }
}

Rozmiar pamięci podręcznej można skonfigurować przez FirestoreSettings. Domyślnie używana jest wartość 100 MB, ale dla aplikacji z intensywnym odczytem danych można ją zwiększyć. Dostępny jest również tryb persistent disk cache, który przetrwa ponowne uruchomienie aplikacji. Do zarządzania dostępnością trybu offline używana jest metoda enableNetwork i disableNetwork, umożliwiające tymczasowe wyłączanie komunikacji sieciowej.

Bezpieczeństwo i zasady dostępu Firestore

Firestore Security Rules to deklaratywny język znaczników do kontroli dostępu do danych na poziomie serwera. Reguły określają, kto i pod jakimi warunkami może czytać i zapisywać dokumenty. Działają przed wykonaniem zapytania i nie wymagają osobnej logiki serwerowej do autoryzacji. Reguły są sprawdzane po stronie Firebase przed każdym odczytem lub zapisem danych.

Zasady dostępu są budowane na zasadzie dozwolonego dostępu (allow). Domyślnie cały dostęp jest zabroniony. Deweloper sukcesywnie otwiera dostęp dla konkretnych operacji (read, write, create, update, delete) pod określonymi warunkami. Warunki mogą sprawdzać uwierzytelnienie użytkownika przez request.auth, dane zapytania przez request.resource i istniejące dane przez resource.

// Zasady dostępu Firestore
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Użytkownik czyta i zapisuje tylko swoje dane
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // Każdy uwierzytelniony może czytać posty
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

Walidacja danych przez reguły

Oprócz kontroli dostępu, Security Rules umożliwiają walidację struktury i typów zapisywanych danych. Na przykład można sprawdzić, czy pole email pasuje do wyrażenia regularnego, lub czy wiek nie przekracza 120 lat. Walidacja jest wykonywana przed zapisem, co zapobiega przechowywaniu nieprawidłowych danych na serwerze. Do sprawdzania pól używany jest obiekt request.resource.data, zawierający cały zapisywany dokument.

Firestore obsługuje również kolekcje dostępne tylko do zapisu serwerowego przez Admin SDK, bez dostępu ze strony klientów. Jest to wygodne do przechowywania danych pomocniczych, kluczy API i konfiguracji, które nie powinny być widoczne dla użytkowników. W tym celu w regułach wystarczy zabronić wszystkich operacji klienckich na odpowiednich kolekcjach, zezwalając na dostęp tylko przez Admin SDK po stronie serwera.

Przykład użycia Firebase Firestore w Android

Rozważmy przykład integracji Firestore z aplikacją Android do tworzenia listy zadań (todo). Aplikacja będzie odczytywać zadania w czasie rzeczywistym, dodawać nowe i oznaczać wykonane. Do asynchronicznej pracy używane są interfejsy callback Firebase i korutyny Kotlin.

Konfiguracja Firebase i dodawanie zależności

Przed rozpoczęciem pracy należy podłączyć projekt do Firebase przez Firebase Console i dodać plik google-services.json do modułu aplikacji. Następnie w build.gradle dodawana jest zależność firebase-firestore-ktx i wtyczka google-services. Wersja biblioteki powinna odpowiadać aktualnej wersji BoM Firebase dla zachowania kompatybilności wszystkich komponentów Firebase.

dependencies {
    // Firebase BoM — zarządzanie wersjami
    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"
}

Po konfiguracji tworzony jest model danych Task i repozytorium do pracy z Firestore. Model zawiera pola id, title, isCompleted i timestamp. Firestore automatycznie serializuje data class do dokumentu, używając nazw pól jako kluczy. Do odczytu danych używany jest snapshot listener, który zwraca Flow przez rozszerzenie 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))
    }
}

View-model subskrybuje Flow z repozytorium i przekazuje listę zadań do warstwy interfejsu. Przy dodawaniu nowego zadania wywoływana jest suspend-funkcja repozytorium przez korutinowy scope. Firestore automatycznie synchronizuje zmiany między wszystkimi klientami: jeśli zadanie doda jeden użytkownik, pozostali widzą je w czasie rzeczywistym bez przeładowania ekranu.