Firebase Realtime DB — какво е това, архитектура и работа с JSON

Какво е Firebase Realtime Database?

Firebase Realtime Database — това е облачна NoSQL база данни, която съхранява и синхронизира данни в реално време между всички свързани клиенти. Създадена през 2012 г. като Firebase (преди придобиването от Google), тя стана първата облачна база данни в реално време за мобилни разработчици. Данните са представени във формат JSON и са организирани в йерархично дърво, където всеки възел има уникален път.

Основната стойност на Realtime Database е вградената синхронизация. Когато приложението промени данни на което и да е устройство, всички останали свързани клиенти незабавно получават актуализацията чрез постоянна връзка. Това освобождава разработчика от реализацията на собствен механизъм за синхронизация, WebSocket сървър или REST API за предаване на данни между клиентите.

Базата данни предоставя SDK за всички основни платформи: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) и сървърни среди чрез Admin SDK. Според данните на Google, Realtime Database се използва в повече от 1,5 милиона активни проекта на Firebase по целия свят. Въпреки появата на по-модерната Firestore, Realtime Database остава популярен избор за проекти с проста структура на данните.

Структура на данните: JSON дърво

За разлика от релационните бази, Realtime Database не използва таблици и редове. Всички данни представляват едно JSON дърво, което изглежда като вложени JavaScript обекти. Например, за съхраняване на потребители и техните съобщения се създава йерархия: users/userId/name и messages/messageId/text. Всеки път в дървото е низ и до данните може да се осъществява достъп директно по този път.

{
  "users": {
    "user1": {
      "name": "Иван Петров",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "Мария Соколова",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "Здравей!",
      "userId": "user1"
    }
  }
}

Важна особеност — дълбоката вложеност влияе на производителността. Когато приложението чете данни по определен път, то зарежда всички дъщерни възли на този път. Затова се препоръчва структурата на данните да се проектира възможно най-плоска, като се избягва вложеност по-дълбока от 3–4 нива. За заобикаляне на този проблем се използва денормализация на данните — дублиране на информацията в различни възли на дървото.

Realtime Database срещу Firestore: кога да изберете

Realtime Database и Firestore често се сравняват като две облачни бази данни в реално време от Google. Изборът между тях зависи от конкретните изисквания на проекта: сложността на заявките, изискваната последователност и планираното натоварване. Разбирането на силните страни на всяка база помага да се вземе правилното архитектурно решение.

Основното предимство на Realtime Database е ниската латентност на синхронизацията. Тъй като всички данни се съхраняват в едно JSON дърво без допълнителни слоеве на абстракция, синхронизацията става по-бързо, отколкото във Firestore. За приложения, където скоростта на доставка на актуализациите е критична (чатове, онлайн игри, системи за съвместно редактиране), Realtime Database може да бъде по-подходящ избор.

Кога да използвате Realtime Database

Realtime Database е по-подходяща за сценарии с проста структура на данните и висока честота на обновяване. Типични примери: чатове, харесвания в реално време, индикатори за писане, статуси за присъствие на потребители. Това е също добър избор за прототипи и проекти с ограничен бюджет, тъй като ценообразуването се основава на обема на данните, а не на броя на операциите.

От друга страна, за приложения със сложни заявки (филтриране по няколко полета, сортиране, агрегиране) Firestore предоставя много по-мощни възможности. Realtime Database поддържа само филтриране по един параметър и не може да сортира резултатите по няколко полета едновременно. Ако проектът планира сложна аналитика на данни в клиента, Firestore ще бъде по-практичен избор.

Как работи синхронизацията в Realtime Database

Realtime Database използва постоянна WebSocket връзка за двупосочна синхронизация на данни. Когато клиентът извика setValue или updateChildren на определен път, данните се изпращат до сървъра на Firebase през отворен канал. Сървърът прилага промените и разпраща актуализациите до всички абонирани клиенти в рамките на милисекунди. Всяка връзка се идентифицира с уникален ключ на сесията.

Механизмът за абонамент работи чрез listeners. Разработчикът може да се абонира за промяна на конкретен възел (addListenerForSingleValueEvent) или да получава постоянни актуализации (addValueEventListener). При всяка промяна на данните се извиква callback onDataChange с пълна снимка на данните по указания път. Това се различава от Firestore, където идват само променените документи — в Realtime Database винаги се зареждат всички данни на възела.

Офлайн режим и управление на конфликти

Realtime Database поддържа офлайн режим на Android и iOS чрез дисково кеширане. SDK съхранява локално копие на данните и продължава да обработва операции за запис при липса на мрежа. Когато връзката се възстанови, всички натрупани промени се изпращат до сървъра. За разрешаване на конфликти се използва стратегията last-write-wins, но разработчикът може да реализира персонализирана логика чрез ServerValue.TIMESTAMP за разрешаване на колизии.

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

// Запис на данни
myRef.push().setValue(
    hashMapOf(
        "text" to "Ново съобщение",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Четене с постоянно обновяване
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "Данни: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "Грешка: ${error.message}")
    }
})

За оптимизиране на трафика и производителността се препоръчва използването на child listeners вместо value listeners, когато трябва да се следят промените на конкретни дъщерни възли. ChildEventListener предоставя отделни callback за добавяне, промяна, изтриване и преместване на дъщерни елементи, което позволява по-точно контролиране на актуализациите на UI и избягване на прерисуването на всички елементи на списъка при всяка промяна на данните.

Правила за сигурност и валидация на данни

Realtime Database използва декларативен език за правила за контрол на достъпа до данните. Правилата описват кой може да чете и пише данни по всеки път на JSON дървото. Те се проверяват на сървъра на Firebase преди всяка заявка и не изискват сървърна логика за авторизация. Правилата поддържат променливи, вградени обекти и функции за гъвкаво настройване на достъпа.

По подразбиране достъпът до базата данни е забранен за всички потребители. Разработчикът последователно отваря достъпа, като използва правилото ".read" и ".write" на различни нива на дървото. Условията могат да проверяват удостоверяването чрез променливата auth, типа на заявката (read/write) и съществуващите данни чрез обекта data. Освен това правилата поддържат валидация на записваните данни чрез обекта newData.

{
  "rules": {
    "users": {
      "$uid": {
        // Само собственикът може да чете своите данни
        ".read": "$uid === auth.uid",
        // Само собственикът може да пише
        ".write": "$uid === auth.uid",
        // Валидация на полетата при запис
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Всеки удостоверен може да чете
      ".read": "auth !== null",
      // Само удостоверен може да пише
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

Правилата също поддържат индексиране на данните чрез директивата ".indexOn". Без нея заявките със сортиране (orderByChild) ще бъдат отхвърлени или ще се изпълняват неефективно. Индексите се указват за всеки път, където се извършва сортиране по определено поле. Правилата са каскадни: по-дълбоките правила преопределят родителските и ако на някое ниво няма достъп, той се счита за разрешен или забранен в зависимост от родителското правило.

Типове данни и ограничения

Realtime Database поддържа пет типа данни: String, Number, Boolean, Map (обект) и List (масив). Дълбочината на вложеност е ограничена до 32 нива, а максималният размер на един възел не трябва да надвишава 256 MB. За ефективна работа с базата данни се препоръчва проектиране на плоска структура на данните и използване на денормализация, за да се избегнат дълбоки заявки, зареждащи големи обеми данни.

Пример за използване на Realtime Database в Android

Ще разгледаме практически пример за интегриране на Realtime Database в Android приложение за статуси на потребители (online/offline). Приложението ще показва списък с потребители и техния текущ статус, обновяван в реално време. За демонстрация се използват Firebase Authentication за идентификация на потребители и корутини за асинхронни операции.

Настройка на зависимости и инициализация

За да започнете, добавете зависимостта firebase-database-ktx във файла build.gradle на модула на приложението. Версията на библиотеката се управлява чрез Firebase BoM, за да се осигури съвместимост на всички компоненти. След добавяне на зависимостта е необходимо да се инициализира Firebase в класа Application или чрез мързелива инициализация във 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"
}

След настройката се създава хранилище (repository) за работа с потребителите. Всеки потребител е представен от възел в дървото /users/{uid} с полета name, email и status. За проследяване на статуса се използва onDisconnect — специален механизъм на Firebase, който автоматично изпълнява операция за запис при прекъсване на връзката на клиента. Това гарантира, че статусът на потребителя ще се промени на "offline" при затваряне на приложението или загуба на мрежа, без допълнителен код от страна на клиента.

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

Ключовият елемент на примера е onDisconnect. Този механизъм позволява да се зададе операция за запис, която ще бъде изпълнена на сървъра при прекъсване на връзката на клиента. В този случай при изключване на потребителя статусът му автоматично се задава на "offline", без да е необходимо да се обработва събитието за затваряне на приложението. Ако приложението приключи аварийно, Firebase сам ще изпълни onDisconnect операцията и другите потребители ще видят коректен статус.