Lovable creează un serviciu în timp real pentru centralizarea permisiunilor privind datele

Lovable a relatat la 9 noiembrie 2026 că, odată cu implementarea completă a Lovable Realtime, interfața sa frontend a renunțat la Firestore. Serviciul personalizat centralizează autorizarea și a atins un vârf de 2,06 milioane de abonamente concurente în perioada de măsurare de 30 de zile.

Migrarea plasează deciziile privind accesul și câmpurile vizibile în backendul Go al Lovable. Pentru platforma companiei de creare a aplicațiilor cu ajutorul IA, serviciul oferă o modalitate de a combina datele din Firestore și Spanner și de a actualiza vizualizarea unui utilizator atunci când se modifică fie informațiile subiacente, fie permisiunile acelui utilizator.

Centralizarea permisiunilor și a datelor în timp real

Unele componente ale Lovable foloseau anterior abonări la Firestore din browser onSnapshot pentru a primi actualizări. Browserul primea documente întregi, iar regulile Firestore trebuiau să reproducă modelul de permisiuni al API-ului Go. Prin această abordare, expunerea datelor devenea și o consecință a modificărilor obișnuite ale documentelor: cineva care adăuga un câmp putea determina ce ajungea în browserele utilizatorilor fără să-și dea neapărat seama de această consecință.

Regulile Firestore pot interoga datele Firebase, dar nu și Spanner, ceea ce îngreuna actualizarea autorizării pentru grupurile mari de întreprinderi sincronizate prin SCIM, care sincronizează utilizatorii și grupurile într-un spațiu de lucru Lovable. Un proxy temporar prin API-ul Go, destinat clienților business și enterprise, reutiliza verificările de permisiuni ale API-ului. De asemenea, acesta deschidea abonări Firestore separate în amonte pentru dependențele fiecărui client, duplicând fluxurile și consumând capacitatea unui grup de conexiuni partajat cu solicitările obișnuite către baza de date.

Lovable a cerut ca soluția de înlocuire să funcționeze cu ambele baze de date existente, să reevalueze continuu accesul și să închidă fluxul unui utilizator căruia i s-au revocat permisiunile chiar în timpul sesiunii. Compania a dorit, de asemenea, ca orice câmp neautorizat să fie reținut înainte ca datele să părăsească serverul. Potrivit evaluării companiei, opțiunile de transport, sincronizare și integrare cu baza de date pe care le-a analizat nu ofereau această combinație fără lucrări substanțiale de integrare, schimbarea bazei de date sau replicarea datelor în Postgres.

Serviciul Go rezultat rulează pe GKE și deschide câte un WebSocket pentru fiecare filă de browser, multiplexând abonamentele prin acea conexiune. Fluxurile de captare a modificărilor din date transportă schimbările din Firestore și Spanner printr-o punte către NATS, magistrala de mesaje a serviciului. Abonamentele corespunzătoare își recalculează vizualizările, compară hash-uri xxh3-128 și trimit diferențe numai atunci când rezultatul se modifică. Un singur abonament poate prelua date din ambele baze de date, aplicând în același timp cadrul de permisiuni al API-ului.

Autorizarea este tratată ca o altă sursă reactivă de date, astfel încât modificările permisiunilor să poată declanșa rezultate noi independent de editările obișnuite ale documentelor. Lovable a raportat că recalcularea permisiunilor doar atunci când se modificau câmpurile implicate în deciziile de acces, în loc să o facă la fiecare actualizare relevantă a documentelor, a redus aceste recalculări cu aproximativ 84%. Serviciul are aproximativ 40 de tipuri de abonamente, gestionate de șapte echipe, cu interfețe tipizate, abonamente partajate pe server și alerte direcționate către echipe.

Traficul în umbră a validat lansarea

La început, Lovable a rulat serviciul în modul umbră: interfața frontend parcurgea întregul flux nou, dar elimina datele utile primite și continua să afișeze conținutul din Firestore. Folosirea traficului real și a structurilor reale ale datelor a scos la iveală valuri de reconectări după implementări, erori clasificate greșit și o limită a dimensiunii datelor utile prea mică pentru datele reale. Apoi, un indicator de funcționalitate a crescut treptat disponibilitatea, de la 1% la 10%, 50% și 100% dintre utilizatori, pe parcursul mai multor zile. Lovable a declarat că lansarea nu a produs niciun incident vizibil pentru utilizatori și nicio regresie în valorile monitorizate.

Deoarece conexiunile WebSocket sunt persistente și pot dura ore întregi, adăugarea de poduri nu redistribuie automat încărcarea existentă. Lovable echilibrează încărcarea în funcție de numărul conexiunilor, scalează folosind atât numărul conexiunilor, cât și utilizarea procesorului și a memoriei și limitează numărul de conexiuni per pod pentru a reduce valurile de reconectări. După reconectare, clienții trimit o amprentă digitală a stării memorate în cache, permițând serverului să confirme, după reverificarea autorizării, că datele nu s-au schimbat, în loc să le retransmită.

Autorul postării a spus că munca practică la nucleul sistemului a durat 40 de zile lucrătoare și că agenții de programare au realizat cea mai mare parte a implementării, după ce arhitectura și cazurile-limită fuseseră clarificate. Un ansamblu de testare a integrării a combinat emulatoare Firestore, Auth și Spanner cu un server NATS încorporat și tokenuri de identificare reale, generate de emulator, permițând agenților să testeze modificările în întregul stivă tehnologică.

Rezultate în producție și posibilitatea de a susține aplicații

Pentru perioada 5 septembrie–5 octombrie 2026, Lovable a raportat 2,61 miliarde de cadre de date și de modificări, fără a include cadrele de control reluate, și a estimat că instantaneele complete pentru fiecare rezultat calculat ar fi generat 40 TB de date utile ale aplicației. Datorită eliminării duplicatelor, diferențelor transmise și reutilizării la reconectare, volumul efectiv de date utile trimise a fost de 1,11 TB, o reducere estimată de 97% față de valoarea de referință. Cifrele privind datele utile nu includ costurile suplimentare ale protocolului și transportului.

Lovable a măsurat intervalul dintre o scriere în baza de date sursă și momentul în care un cadru de ieșire era gata de trimis: 66 de milisecunde la p50 și 249 de milisecunde la p99. Aceste măsurători nu includ scrierile prin socket, timpul de transmisie în rețea sau procesarea de către client și, prin urmare, nu reprezintă timpul total de actualizare perceput de utilizator.

Lovable a declarat că adaugă în mod activ primitive pentru evenimente de domeniu, pentru cazurile în care consumatorii trebuie să fie informați că s-a întâmplat ceva, în loc să primească un instantaneu al datelor, și că serviciul ar putea deveni ulterior o funcționalitate în aplicațiile create cu Lovable. O astfel de extindere ar aduce permisiuni controlate de backend și vizualizări în timp real în aplicațiile create de clienți. Implementarea actuală oferă deja echipelor Lovable o bază comună pentru o colaborare mai amplă, pe măsură ce infrastructura lor de date evoluează.