Firebase Realtime DB — o que é, arquitetura e trabalho com JSON

O que é Firebase Realtime Database?

Firebase Realtime Database é um banco de dados NoSQL em nuvem que armazena e sincroniza dados em tempo real entre todos os clientes conectados. Lançado em 2012 como Firebase (antes da aquisição pelo Google), tornou-se o primeiro banco de dados em nuvem em tempo real para desenvolvedores móveis. Os dados são representados em formato JSON e organizados em uma árvore hierárquica, onde cada nó tem um caminho único.

O valor central do Realtime Database é a sincronização integrada. Quando um aplicativo altera dados em qualquer dispositivo, todos os outros clientes conectados recebem instantaneamente a atualização através de uma conexão persistente. Isso elimina a necessidade de o desenvolvedor implementar seu próprio mecanismo de sincronização, servidor WebSocket ou API REST para transferência de dados entre clientes.

O banco de dados fornece SDKs para todas as principais plataformas: Android (Java, Kotlin), iOS (Swift, Objective-C), Web (JavaScript) e ambientes de servidor via Admin SDK. De acordo com o Google, o Realtime Database é usado em mais de 1,5 milhão de projetos ativos do Firebase em todo o mundo. Apesar do surgimento do Firestore mais moderno, o Realtime Database continua sendo uma escolha popular para projetos com estruturas de dados simples.

Estrutura de dados: árvore JSON

Ao contrário dos bancos de dados relacionais, o Realtime Database não usa tabelas e linhas. Todos os dados são uma única árvore JSON que se assemelha a objetos JavaScript aninhados. Por exemplo, para armazenar usuários e suas mensagens, é criada uma hierarquia: users/userId/name e messages/messageId/text. Cada caminho na árvore é uma string, e os dados podem ser acessados diretamente por este caminho.

{
  "users": {
    "user1": {
      "name": "João Petrov",
      "email": "ivan@example.com"
    },
    "user2": {
      "name": "Maria Sokolova",
      "email": "maria@example.com"
    }
  },
  "messages": {
    "-Nabc123": {
      "text": "Olá!",
      "userId": "user1"
    }
  }
}

Uma característica importante é que o aninhamento profundo afeta o desempenho. Quando um aplicativo lê dados em um determinado caminho, ele carrega todos os nós filhos desse caminho. Portanto, recomenda-se projetar a estrutura de dados o mais plana possível, evitando aninhamentos com mais de 3-4 níveis. Para contornar esse problema, utiliza-se a desnormalização de dados — duplicar informações em diferentes nós da árvore.

Realtime Database vs Firestore: quando escolher

Realtime Database e Firestore são frequentemente comparados como dois bancos de dados em nuvem em tempo real do Google. A escolha entre eles depende dos requisitos específicos do projeto: complexidade das consultas, consistência necessária e carga esperada. Compreender os pontos fortes de cada banco de dados ajuda a tomar a decisão arquitetônica correta.

A principal vantagem do Realtime Database é a baixa latência de sincronização. Como todos os dados são armazenados em uma única árvore JSON sem camadas de abstração adicionais, a sincronização é mais rápida que no Firestore. Para aplicativos onde a velocidade de entrega de atualizações é crítica (chats, jogos online, sistemas de edição colaborativa), o Realtime Database pode ser a escolha mais adequada.

Quando usar Realtime Database

Realtime Database é mais adequado para cenários com estruturas de dados simples e alta frequência de atualização. Exemplos típicos: chats, curtidas em tempo real, indicadores de digitação, status de presença de usuários. Também é uma boa escolha para protótipos e projetos com orçamento limitado, pois o preço é baseado no volume de dados, não no número de operações.

Por outro lado, para aplicativos com consultas complexas (filtragem por vários campos, ordenação, agregação), o Firestore oferece capacidades muito mais poderosas. O Realtime Database suporta apenas filtragem por um parâmetro e não pode ordenar resultados por vários campos simultaneamente. Se um projeto planeja análises de dados complexas no cliente, o Firestore será uma escolha mais prática.

Como funciona a sincronização no Realtime Database

Realtime Database usa uma conexão WebSocket persistente para sincronização bidirecional de dados. Quando um cliente chama setValue ou updateChildren em um caminho específico, os dados são enviados para o servidor Firebase através do canal aberto. O servidor aplica as alterações e distribui as atualizações para todos os clientes inscritos em milissegundos. Cada conexão é identificada por uma chave de sessão única.

O mecanismo de inscrição funciona através de listeners. Um desenvolvedor pode se inscrever em alterações em um nó específico (addListenerForSingleValueEvent) ou receber atualizações contínuas (addValueEventListener). Cada vez que os dados mudam, o callback onDataChange é acionado com um snapshot completo dos dados no caminho especificado. Isso difere do Firestore, onde apenas os documentos alterados são recebidos — no Realtime Database, todos os dados do nó são sempre carregados.

Modo offline e gerenciamento de conflitos

Realtime Database suporta modo offline no Android e iOS através de cache em disco. O SDK mantém uma cópia local dos dados e continua processando operações de gravação quando não há rede. Quando a conexão é restabelecida, todas as alterações acumuladas são enviadas ao servidor. A estratégia de última escrita vence (last-write-wins) é usada para resolução de conflitos, mas os desenvolvedores podem implementar lógica personalizada através de ServerValue.TIMESTAMP para resolução de colisões.

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

// Gravação de dados
myRef.push().setValue(
    hashMapOf(
        "text" to "Nova mensagem",
        "timestamp" to ServerValue.TIMESTAMP
    )
)

// Leitura com atualizações contínuas
myRef.addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val data = snapshot.getValue()
        Log.d("TAG", "Dados: $data")
    }

    override fun onCancelled(error: DatabaseError) {
        Log.w("TAG", "Erro: ${error.message}")
    }
})

Para otimizar tráfego e desempenho, recomenda-se usar child listeners em vez de value listeners ao rastrear alterações em nós filhos específicos. ChildEventListener fornece callbacks separados para adicionar, modificar, remover e mover elementos filhos, permitindo um controle mais preciso das atualizações da interface e evitando redesenhar todos os itens da lista a cada alteração de dados.

Regras de segurança e validação de dados

Realtime Database usa uma linguagem de regras declarativa para controle de acesso a dados. As regras descrevem quem pode ler e escrever dados em cada caminho da árvore JSON. Elas são verificadas no servidor Firebase antes de cada requisição e não exigem lógica de servidor para autorização. As regras suportam variáveis, objetos integrados e funções para configuração flexível de acesso.

Por padrão, o acesso ao banco de dados é negado para todos os usuários. O desenvolvedor abre gradualmente o acesso usando as regras ".read" e ".write" em vários níveis da árvore. As condições podem verificar autenticação através da variável auth, tipo de requisição (leitura/escrita) e dados existentes através do objeto data. Além disso, as regras suportam validação de dados escritos através do objeto newData.

{
  "rules": {
    "users": {
      "$uid": {
        // Apenas o proprietário pode ler seus dados
        ".read": "$uid === auth.uid",
        // Apenas o proprietário pode escrever
        ".write": "$uid === auth.uid",
        // Validação de campos ao escrever
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      // Qualquer usuário autenticado pode ler
      ".read": "auth !== null",
      // Apenas usuário autenticado pode escrever
      ".write": "auth !== null",
      ".indexOn": ["timestamp"]
    }
  }
}

As regras também suportam indexação de dados através da diretiva ".indexOn". Sem ela, consultas com ordenação (orderByChild) serão rejeitadas ou executadas de forma ineficiente. Índices são especificados para cada caminho onde a ordenação por um campo específico é realizada. As regras são em cascata: regras mais profundas substituem regras pai, e se o acesso não estiver definido em algum nível, é considerado permitido ou negado dependendo da regra pai.

Tipos de dados e limitações

Realtime Database suporta cinco tipos de dados: String, Number, Boolean, Map (objeto) e List (array). A profundidade de aninhamento é limitada a 32 níveis, e o tamanho máximo de um único nó não deve exceder 256 MB. Para um trabalho eficiente com o banco de dados, recomenda-se projetar uma estrutura de dados plana e usar desnormalização para evitar consultas profundas que carreguem grandes quantidades de dados.

Exemplo de uso do Realtime Database no Android

Vamos considerar um exemplo prático de integração do Realtime Database em um aplicativo Android para status de usuário (online/offline). O aplicativo exibirá uma lista de usuários com seu status atual, atualizado em tempo real. Para demonstração, são usados Firebase Authentication para identificação de usuários e corrotinas para operações assíncronas.

Configuração de dependências e inicialização

Para começar, adicione a dependência firebase-database-ktx ao arquivo build.gradle do módulo do aplicativo. A versão da biblioteca é gerenciada através do Firebase BoM para garantir compatibilidade de todos os componentes. Após adicionar a dependência, o Firebase deve ser inicializado na classe Application ou através de inicialização preguiçosa no 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"
}

Após a configuração, é criado um repositório para trabalhar com usuários. Cada usuário é representado por um nó na árvore /users/{uid} com campos name, email e status. Para rastreamento de status, é usado onDisconnect — um mecanismo especial do Firebase que executa automaticamente uma operação de gravação quando a conexão do cliente é interrompida. Isso garante que o status do usuário mude para "offline" ao fechar o aplicativo ou perder a rede sem código adicional no cliente.

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

O elemento chave do exemplo é onDisconnect. Este mecanismo permite definir uma operação de gravação que será executada no servidor quando a conexão do cliente for interrompida. Neste caso, quando o usuário se desconecta, seu status é automaticamente definido como "offline" sem necessidade de lidar com o evento de fechamento do aplicativo. Se o aplicativo travar, o Firebase executará a operação onDisconnect, e outros usuários verão o status correto.