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 vs 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). При кожній зміні даних викликається зворотний виклик 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 надає окремі зворотні виклики для додавання, зміни, видалення та переміщення дочірних елементів, що дозволяє точніше керувати оновленнями інтерфейсу та уникати перемалювання всіх елементів списку при кожній зміні даних.

Правила безпеки та валідація даних

Realtime Database використовує декларативну мову правил для контролю доступу до даних. Правила описують, хто може читати та записувати дані на кожному шляху JSON-дерева. Вони перевіряються на сервері Firebase перед кожним запитом та не потребують серверної логіки для авторизації. Правила підтримують змінні, вбудовані об’єкти та функції для гнучкого налаштування доступу.

За замовчуванням, доступ до бази даних заборонено для всіх користувачів. Розробник послідовно відкриває доступ, використовуючи правила ".read" та ".write" на різних рівнях дерева. Умови можуть перевіряти аутентифікацію через змінну auth, тип запиту (читання/запис) та існуючі дані через об’єкт 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-додаток для статусів користувачів (онлайн/офлайн). Додаток відображатиме список користувачів з їхнім поточним статусом, що оновлюється в реальному часі. Для демонстрації використовуються 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"
}

Після налаштування створюється репозиторій для роботи з користувачами. Кожен користувач представлений вузлом в дереві /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-операцію, і інші користувачі побачать коректний статус.