Lovable crea un servizio in tempo reale per centralizzare le autorizzazioni sui dati

Il 9 novembre 2026 Lovable ha riferito di aver completato la migrazione del frontend da Firestore con la distribuzione integrale di Lovable Realtime, un servizio personalizzato che centralizza l’autorizzazione e che, nell’arco di un periodo di misurazione di 30 giorni, ha raggiunto un picco di 2,06 milioni di sottoscrizioni simultanee.

La migrazione affida al backend Go di Lovable le decisioni relative agli accessi e ai campi visibili. Per la piattaforma dell’azienda dedicata alla creazione di app con l’IA, il servizio offre un unico modo per combinare i dati di Firestore e Spanner e aggiornare la visualizzazione di un utente quando cambiano le informazioni sottostanti o le autorizzazioni di quell’utente.

Centralizzare le autorizzazioni e i dati in tempo reale

In precedenza, alcune parti di Lovable utilizzavano Firestore dal browser onSnapshot per ricevere gli aggiornamenti. Il browser riceveva documenti interi, mentre le regole di Firestore dovevano rispecchiare il modello di autorizzazioni dell’API Go. Questa configurazione faceva inoltre sì che l’esposizione dei dati dipendesse dalle normali modifiche ai documenti: chi aggiungeva un campo poteva determinare quali dati sarebbero arrivati ai browser degli utenti senza necessariamente rendersi conto di questa conseguenza.

Le regole di Firestore possono interrogare i dati di Firebase, ma non quelli di Spanner, ostacolando gli aggiornamenti delle autorizzazioni che riguardano grandi gruppi aziendali sincronizzati tramite SCIM, che sincronizza utenti e gruppi con un’area di lavoro Lovable. Per i clienti business ed enterprise è stato introdotto temporaneamente un proxy attraverso l’API Go, che riutilizzava i controlli delle autorizzazioni dell’API. Il proxy apriva inoltre listener Firestore separati a monte per le dipendenze di ciascun client, duplicando i flussi e consumando capacità da un pool di connessioni condiviso con le normali richieste al database.

Lovable richiedeva che la soluzione sostitutiva funzionasse con entrambi i database esistenti, rivalutasse continuamente gli accessi e chiudesse il flusso di un utente a cui erano state revocate le autorizzazioni anche nel corso della sessione. Voleva inoltre che i campi non autorizzati fossero esclusi prima che i dati lasciassero il server. Secondo la valutazione dell’azienda, le soluzioni di trasporto, sincronizzazione e integrazione con il database prese in esame non offrivano questa combinazione senza un notevole lavoro di integrazione, una modifica del database o la replica dei dati in Postgres.

Il servizio Go risultante viene eseguito su GKE e apre una connessione WebSocket per ogni scheda del browser, con le sottoscrizioni multiplexate sulla stessa connessione. I flussi di acquisizione delle modifiche ai dati trasmettono le modifiche di Firestore e Spanner attraverso un bridge verso NATS, il bus di messaggistica del servizio. Le sottoscrizioni corrispondenti ricalcolano le proprie visualizzazioni, confrontano gli hash xxh3-128 e inviano solo le differenze quando l’output cambia. Una singola sottoscrizione può attingere a entrambi i database applicando al contempo il framework di autorizzazioni dell’API.

L’autorizzazione viene trattata come un’ulteriore sorgente di dati reattiva, così che le modifiche alle autorizzazioni possano attivare nuovi risultati indipendentemente dalle normali modifiche ai documenti. Lovable ha riferito che ricalcolare i risultati solo quando cambiavano i campi coinvolti nelle decisioni di accesso, anziché a ogni aggiornamento pertinente dei documenti, ha ridotto di circa l’84% i ricalcoli delle autorizzazioni. Il servizio conta circa 40 tipi di sottoscrizione, gestiti da sette team, con interfacce tipizzate, sottoscrizioni condivise lato server e avvisi instradati ai team.

Il traffico in modalità ombra ha convalidato il rilascio

Inizialmente, Lovable ha eseguito il servizio in modalità ombra: il frontend percorreva l’intero nuovo flusso, ma scartava i payload e continuava a visualizzare i dati provenienti da Firestore. L’uso di traffico reale e di strutture dati effettive ha fatto emergere ondate di riconnessioni dopo le distribuzioni, errori classificati in modo errato e un limite alle dimensioni dei payload troppo basso per i dati reali. Nei giorni successivi, un flag di funzionalità ha esteso gradualmente il rilascio dall’1% al 10%, al 50% e infine al 100% degli utenti. Lovable ha dichiarato che il rilascio non ha causato incidenti visibili agli utenti né regressioni nelle metriche monitorate.

Poiché le connessioni WebSocket sono persistenti e possono durare ore, aggiungere pod non basta, di per sé, a spostare il carico esistente. Lovable bilancia il carico in base al numero di connessioni, scala considerando le connessioni insieme alla CPU e alla memoria e limita il numero di connessioni per pod per contenere le ondate di riconnessioni. Dopo essersi riconnessi, i client inviano un’impronta del proprio stato memorizzato nella cache, consentendo al server, dopo aver ricontrollato le autorizzazioni, di confermare che i dati non sono cambiati invece di trasmetterli di nuovo.

L’autore del post ha dichiarato che il lavoro di base ha richiesto 40 giornate lavorative effettive e che gli agenti di programmazione hanno gestito la maggior parte dell’implementazione una volta definiti l’architettura e i casi limite. Un ambiente di integrazione combinava emulatori di Firestore, Auth e Spanner con un server NATS integrato e token ID reali generati dagli emulatori, consentendo agli agenti di testare le modifiche sull’intero stack.

Risultati in produzione e potenziale supporto per le app

Per il periodo dal 5 settembre al 5 ottobre 2026, Lovable ha riportato 2,61 miliardi di frame di dati e patch, esclusi i frame di controllo ripresi, e ha stimato che la generazione di snapshot completi per ogni risultato calcolato avrebbe prodotto 40 TB di payload applicativo. La deduplicazione, le differenze e il riutilizzo dopo le riconnessioni hanno ridotto il payload effettivamente inviato a 1,11 TB, una riduzione stimata del 97% rispetto a quel valore di riferimento. Le cifre relative ai payload non includono l’overhead del protocollo e del trasporto.

Lovable ha misurato l’intervallo tra una scrittura nel database sorgente e la disponibilità di un frame in uscita pronto per l’invio: 66 millisecondi al p50 e 249 millisecondi al p99. Queste misurazioni escludono le scritture sul socket, il tempo di rete e l’elaborazione sul client, quindi non rappresentano il tempo complessivo di aggiornamento percepito dall’utente.

Lovable ha dichiarato che sta aggiungendo attivamente primitive per gli eventi di dominio nei casi in cui i consumatori debbano essere informati del verificarsi di un evento, anziché ricevere uno snapshot dei dati, e che in futuro il servizio potrebbe diventare una funzionalità integrata nelle app create con Lovable. Una simile estensione porterebbe nelle applicazioni create dai clienti permessi gestiti dal backend e viste in tempo reale. L’implementazione attuale offre già ai team di Lovable una base condivisa per una collaborazione più articolata, mentre la loro infrastruttura dati continua a evolversi.