Lovable cria serviço em tempo real para centralizar permissões de acesso a dados

Em 9 de novembro de 2026, Lovable informou que concluiu a migração de seu frontend para fora do Firestore com a implantação completa do Lovable Realtime, um serviço personalizado que centraliza a autorização e atingiu um pico de 2,06 milhões de assinaturas simultâneas durante um período de medição de 30 dias.

A migração transfere para o backend em Go da Lovable as decisões sobre o acesso e os campos visíveis. Para a plataforma de criação de aplicativos com IA da empresa, o serviço oferece uma forma de combinar dados do Firestore e do Spanner e atualizar a visualização de um usuário quando mudam os dados subjacentes ou as permissões desse usuário.

Centralização de permissões e dados em tempo real

Partes da Lovable usavam anteriormente listeners do Firestore no navegador onSnapshot para receber atualizações. O navegador recebia documentos inteiros, enquanto as regras do Firestore precisavam espelhar o modelo de permissões da API em Go. Esse projeto também fazia com que a exposição de dados se tornasse uma consequência de alterações rotineiras nos documentos: alguém que adicionasse um campo poderia determinar o que chegaria aos navegadores dos usuários sem necessariamente perceber essa consequência.

As regras do Firestore podem consultar dados do Firebase, mas não do Spanner, o que cria um obstáculo para atualizações de autorização que afetam grandes grupos empresariais sincronizados por meio do SCIM, que sincroniza usuários e grupos com um espaço de trabalho da Lovable. Um proxy temporário pela API em Go, destinado a clientes empresariais e corporativos, reutilizava as verificações de permissão da API. Ele também abria listeners separados do Firestore a montante para as dependências de cada cliente, duplicando fluxos e consumindo capacidade de um pool de conexões compartilhado com as solicitações comuns ao banco de dados.

A Lovable exigiu que a solução substituta funcionasse com os dois bancos de dados existentes, reavaliasse continuamente o acesso e encerrasse o fluxo de um usuário cuja autorização fosse revogada, mesmo no meio de uma sessão. A empresa também queria que os campos não autorizados fossem retidos antes que qualquer dado saísse do servidor. Na avaliação da empresa, as opções de transporte, sincronização e integração com bancos de dados que examinou não ofereciam essa combinação sem um trabalho substancial de integração, uma mudança de banco de dados ou a replicação dos dados no Postgres.

O serviço resultante, escrito em Go, é executado no GKE e abre um WebSocket por aba do navegador, multiplexando as assinaturas nessa conexão. Fluxos de captura de alterações nos dados levam as mudanças do Firestore e do Spanner por uma ponte até o NATS, o barramento de mensagens do serviço. As assinaturas correspondentes recalculam suas visualizações, comparam hashes xxh3-128 e enviam atualizações incrementais somente quando o resultado muda. Uma única assinatura pode obter dados dos dois bancos de dados e, ao mesmo tempo, aplicar a estrutura de permissões da API.

A autorização é tratada como outra fonte de dados reativa, permitindo que mudanças nas permissões acionem novos resultados independentemente das edições comuns em documentos. A Lovable informou que recalcular os resultados somente quando mudavam os campos envolvidos nas decisões de acesso — em vez de a cada atualização relevante de documento — reduziu em cerca de 84% os recálculos de permissões. O serviço conta com aproximadamente 40 tipos de assinatura, mantidos por sete equipes, além de interfaces tipadas, assinaturas compartilhadas no servidor e alertas encaminhados às equipes responsáveis.

Tráfego em modo sombra validou a implantação

Primeiro, a Lovable executou o serviço em modo sombra: o frontend percorreu todo o novo fluxo, mas descartou os dados recebidos e continuou renderizando as informações do Firestore. O uso de tráfego real e de estruturas de dados reais revelou picos de reconexões após implantações, erros classificados incorretamente e um limite de tamanho dos dados recebidos que era pequeno demais para dados reais. Em seguida, um sinalizador de funcionalidade aumentou a disponibilidade para 1%, 10%, 50% e, por fim, 100% dos usuários ao longo de vários dias. A Lovable afirmou que a implantação não causou nenhum incidente visível para os usuários nem regressão nas métricas monitoradas.

Como as conexões WebSocket são persistentes e podem durar horas, adicionar pods não transfere, por si só, a carga existente. A Lovable distribui a carga com base no número de conexões, escala considerando as conexões junto com o uso de CPU e memória e limita o número de conexões por pod para reduzir ondas de reconexão. Após se reconectarem, os clientes enviam uma impressão digital do estado em cache, permitindo que o servidor confirme, depois de revalidar a autorização, que os dados não mudaram, em vez de transmiti-los novamente.

O autor da publicação disse que o trabalho principal levou 40 dias úteis de trabalho prático e que os agentes de programação realizaram a maior parte da implementação depois que a arquitetura e os casos extremos foram definidos. Uma estrutura de integração combinou emuladores do Firestore, do Auth e do Spanner com um servidor NATS incorporado e tokens de ID reais, emitidos pelos emuladores, permitindo que os agentes testassem mudanças em toda a pilha.

Resultados em produção e possível suporte a aplicativos

Para o período de 5 de setembro a 5 de outubro de 2026, a Lovable informou o envio de 2,61 bilhões de quadros de dados e de patches, sem contar os quadros de controle retomados, e estimou que instantâneos completos de cada resultado calculado teriam gerado 40 TB de dados úteis da aplicação. A deduplicação, as atualizações incrementais e o reaproveitamento após reconexões reduziram os dados úteis efetivamente enviados para 1,11 TB, uma redução estimada de 97% em relação a esse valor de referência. Os números de dados úteis não incluem a sobrecarga dos protocolos e do transporte.

A Lovable mediu em 66 milissegundos no p50 e 249 milissegundos no p99 o intervalo entre uma gravação no banco de dados de origem e a preparação de um quadro de saída para envio. Essas medições não incluem a gravação no socket, o tempo de rede nem o processamento no cliente e, portanto, não representam o tempo total até que o usuário perceba a atualização.

A Lovable afirmou que está adicionando ativamente primitivas de eventos de domínio para os casos em que os consumidores precisam ser avisados de que algo aconteceu, em vez de receber um instantâneo dos dados, e que, futuramente, o serviço poderá se tornar um recurso integrado aos aplicativos criados com a Lovable. Essa extensão levaria permissões controladas pelo back-end e visualizações em tempo real aos aplicativos criados pelos clientes. A implantação atual já oferece às equipes da Lovable uma base compartilhada para uma colaboração mais ampla, à medida que a infraestrutura de dados evolui.