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

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

A 9 de novembro de 2026, a Lovable informou que concluiu a migração do seu frontend para fora do Firestore, com a implementação total do Lovable Realtime, um serviço próprio que centraliza a autorização e que atingiu um pico de 2,06 milhões de subscrições simultâneas ao longo de 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 aplicações com IA da empresa, o serviço permite combinar dados do Firestore e do Spanner e atualizar a vista de um utilizador quando os dados subjacentes ou as permissões desse utilizador mudam.

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

Antes, algumas partes da Lovable usavam os listeners onSnapshot do Firestore no navegador para receber atualizações. O navegador recebia documentos inteiros, enquanto as regras do Firestore tinham de espelhar o modelo de permissões da API em Go. Segundo a empresa, isto fazia com que a exposição de dados fosse uma consequência de alterações rotineiras nos documentos: alguém que acrescentasse um campo podia determinar o que chegaria aos navegadores dos utilizadores sem necessariamente dar por 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 através de SCIM, protocolo que sincroniza utilizadores e grupos com um espaço de trabalho da Lovable. Um proxy temporário através da API em Go, destinado a clientes empresariais e corporativos, reutilizava as verificações de permissão da API, mas também abria listeners separados do Firestore a montante para as dependências de cada cliente, duplicando fluxos e consumindo capacidade de uma pool de partilhada com os pedidos comuns à base de dados.

A Lovable exigia que a solução substituta funcionasse com as duas bases de dados existentes, reavaliasse continuamente o acesso e encerrasse o fluxo de um utilizador cuja autorização fosse revogada, mesmo a meio de uma sessão. A empresa queria também que os campos não autorizados fossem retidos antes de qualquer dado sair do servidor. Na sua avaliação, as opções de transporte, sincronização e integração com bases de dados que analisou não ofereciam essa combinação sem um trabalho substancial de integração, uma mudança de base de dados ou a replicação dos dados em Postgres.

O serviço resultante, escrito em Go e executado no GKE, abre um WebSocket por separador do navegador, multiplexando as subscrições nessa ligação. Fluxos de captura de alterações transportam as mudanças do Firestore e do Spanner através de uma ponte até ao NATS, o barramento de mensagens do serviço. As subscrições correspondentes recalculam as suas vistas, comparam hashes xxh3-128 e enviam atualizações incrementais apenas quando o resultado muda. Uma única subscrição pode obter dados das duas bases 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 desencadeiem novos resultados, independentemente das edições comuns em documentos. A Lovable indicou que recalcular os resultados apenas quando mudavam os campos envolvidos nas decisões de acesso — e não 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 subscrição, mantidos por sete equipas, além de interfaces tipadas, subscrições partilhadas no servidor e alertas encaminhados às equipas responsáveis.

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

Em primeiro lugar, a Lovable executou o serviço em modo sombra: o frontend percorria todo o novo fluxo, mas descartava os dados recebidos e continuava a renderizar as informações do Firestore. O uso de tráfego real e de estruturas de dados reais revelou picos de reconexão após implementações, erros classificados incorretamente e um limite de tamanho dos dados recebido que era pequeno demais para dados reais. Seguidamente, um marcador de funcionalidade aumentou a disponibilidade para 1%, 10%, 50% e, por fim, 100% dos utilizadores ao longo de vários dias. A Lovable afirmou que a implementação não causou nenhum incidente visível para os utilizadores nem regressão nas métricas monitorizadas.

Como as ligaçõ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 ligações, dimensiona tendo em conta as ligações juntamente com o uso de CPU e memória e limita o número de ligações por pod para reduzir ondas de reconexão. Depois de se reconectarem, os clientes enviam uma impressão digital do estado em cache, o que permite ao servidor confirmar, após revalidar a autorização, que os dados não mudaram, em vez de os transmitir novamente.

O autor da publicação indicou que o trabalho principal levou 40 dias úteis de trabalho efetivo e que os agentes de programação realizaram a maior parte da implementação depois de a arquitetura e os casos-limite terem sido 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 alterações em toda a pilha.

Resultados em produção e possível suporte a aplicações

Para o período de 5 de setembro a 5 de outubro de 2026, a Lovable informou o envio de 2,61 mil milhões de quadros de dados e de patches, sem contar os quadros de controlo 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 a reutilização após reconexões reduziram os dados úteis efetivamente enviados para 1,11 TB, uma redução estimada de 97% face a esse valor de referência. Os valores não incluem a sobrecarga dos protocolos e do transporte.

A Lovable mediu 66 milissegundos no p50 e 249 milissegundos no p99 no intervalo entre uma escrita na base de dados de origem e a preparação de um quadro de saída para envio. Estas medições não incluem a escrita no socket, o tempo de rede nem o processamento no cliente e, por isso, não representam o tempo total até o utilizador perceber a atualização.

A empresa afirmou que está a adicionar ativamente primitivas de eventos de domínio para os casos em que os consumidores precisam de ser avisados de que algo aconteceu, em vez de receberem um instantâneo dos dados, e que, no futuro, o serviço poderá tornar-se um recurso integrado nas aplicações criadas com a Lovable. Essa extensão levaria permissões controladas pelo backend e vistas em tempo real às aplicações criadas pelos clientes. A implementação atual já oferece às equipas da Lovable uma base partilhada para uma colaboração mais alargada, à medida que a infraestrutura de dados evolui.

Porque importa

A centralização da autorização num único serviço em tempo real responde a um problema concreto de segurança: evitar que alterações rotineiras em documentos exponham dados que não deveriam chegar aos navegadores dos utilizadores. Os resultados apresentados — 84% menos recálculos de permissões e 97% menos dados úteis enviados face a uma hipótese de instantâneos completos — sugerem ganhos relevantes de eficiência à escala em que a plataforma opera. A Lovable não descarta ainda transformar o serviço num recurso disponível nas aplicações criadas pelos seus clientes, o que estenderia o modelo a outros produtos.