Lovable move as atualizações para o próprio servidor e reduz o volume de dados em cerca de 97%

Adiciona-se um campo interno ao documento de um projeto, e o navegador do usuário já pode recebê-lo. A Lovable corria esse risco enquanto o frontend se inscrevia diretamente nos documentos do Firestore. O desenvolvedor precisava pensar na API pública mesmo em uma alteração comum da estrutura do banco. Além disso, as permissões de acesso tinham de ser mantidas de forma consistente em dois lugares: nas regras do Firestore e no código de servidor em Go.

A equipe transferiu as atualizações para um serviço próprio, o Lovable Realtime. Agora o servidor define quais campos enviar a cada usuário e reavalia essa decisão quando dados ou permissões mudam. Segundo a Lovable, o serviço suportou um pico de 2,06 milhões de assinaturas simultâneas. O interesse prático está em como as assinaturas são organizadas, como as permissões são verificadas e como um produto em operação foi migrado.

O que acontece após a revogação do acesso

Imagine o espaço de trabalho de uma empresa. Um funcionário abriu um projeto e, em seguida, o administrador o removeu do grupo com acesso. A aba já aberta deve parar de receber atualizações. Quando o conjunto de permissões muda, o servidor também pode precisar remover campos específicos das respostas seguintes.

Na Lovable, a verificação de acesso foi transformada em uma fonte de dados rastreável, como o próprio projeto. A assinatura depende tanto do conteúdo do projeto quanto das permissões do usuário. A alteração de qualquer uma dessas dependências faz o servidor recalcular o resultado disponível ao usuário. Na revogação do acesso, o fluxo deve ser encerrado no meio da sessão.

Isso foi especialmente útil para grupos corporativos: as informações necessárias estavam em bancos diferentes, Firestore e Spanner. As regras de segurança do Firestore não conseguiam ler o Spanner. Uma camada de servidor própria permitiu combinar dados de ambos os bancos em uma única resposta e aplicar o sistema comum de permissões da API.

No entanto, essa solução tem um custo. No início, qualquer alteração no documento do projeto disparava um recálculo completo das permissões, inclusive a edição comum de arquivos. A equipe manteve o recálculo apenas para mudanças nos campos que participam da decisão de acesso. Segundo seus dados, o número de recálculos caiu cerca de 84%. A lista desses campos precisa ser mantida como parte da lógica de autorização; uma verificação estática separada ajuda a encontrar omissões nos pacotes que ela cobre.

Como as atualizações chegam ao navegador

Cada aba usa uma conexão WebSocket, dentro da qual funcionam várias assinaturas. As alterações do Firestore e do Spanner chegam por um mecanismo de captura de mudanças a uma ponte e, depois, ao NATS. O serviço em Go recebe o evento e recalcula as assinaturas afetadas.

Em seguida, compara o hash do novo resultado com o anterior. Se nada mudou para o usuário, não há o que enviar. Se mudou, é possível transmitir apenas a diferença. Vários componentes da interface com a mesma assinatura compartilham automaticamente uma única assinatura no servidor.

Na reconexão, o navegador envia uma impressão digital do estado salvo. O servidor verifica novamente as permissões e carrega os dados atuais. Se o resultado coincide, confirma que o cache pode ser usado sem retransmitir todo o conteúdo.

Nos 30 dias citados no artigo, o serviço entregou 2,61 bilhões de quadros com dados e alterações. A equipe estimou em 40 TB a transmissão hipotética de cada resultado calculado por inteiro. O volume efetivamente transmitido foi de 1,11 TB, graças à supressão de repetições, ao envio de diferenças e à reutilização do estado na reconexão. Daí a estimativa de redução de cerca de 97%. Trata-se de uma comparação com uma base calculada de respostas completas, e não de uma redução medida dos custos do Firestore.

O que levar para o seu produto

A migração começou em modo sombra: o navegador se inscrevia no novo serviço, mas continuava exibindo dados do Firestore. Assim, a equipe descobriu ondas de reconexões após implantações, erros de classificação de falhas e um limite de tamanho de resposta pequeno demais. Depois, a parcela de usuários foi aumentada em etapas. Segundo a Lovable, a migração ocorreu sem incidentes para os usuários.

Para a operação, importa mais um detalhe: adicionar servidores não alivia as conexões longas já estabelecidas. Por isso, a Lovable limita o número de conexões por instância do serviço, mantém uma reserva de memória e distribui no tempo as reconexões após uma implantação.

Nem toda equipe precisará construir um sistema assim do zero. Aqui, a escolha foi determinada pelos bancos existentes, pelo backend em Go e pelo requisito de alterar permissões durante a sessão. Mas é possível verificar o seu próprio produto agora mesmo: quais campos vão para o navegador, o que acontece após a revogação do acesso e se o servidor suporta o retorno simultâneo de muitas abas.