Lovable bygger en realtidstjeneste, der samler dataadgangskontrollen ét sted

Lovable oplyste den 9. november 2026, at virksomhedens frontend var flyttet væk fra Firestore med den fulde udrulning af Lovable Realtime, en specialudviklet tjeneste, der samler autorisationen ét sted, og som nåede op på 2,06 millioner samtidige abonnementer på sit højeste i løbet af en måleperiode på 30 dage.

Med migreringen placeres beslutninger om adgang og synlige felter i Lovables Go-backend. For virksomhedens platform til AI-appudvikling giver tjenesten én måde at kombinere data fra Firestore og Spanner på og opdatere en brugers visning, når enten de underliggende oplysninger eller brugerens tilladelser ændres.

Samling af tilladelser og live-data ét sted

Dele af Lovable brugte tidligere Firestore i browseren onSnapshot til at lytte efter opdateringer. Browseren modtog hele dokumenter, mens Firestore-reglerne skulle afspejle Go API’ets tilladelsesmodel. Designet betød også, at eksponering af data blev en del af de almindelige dokumentændringer: En person, der tilføjede et felt, kunne afgøre, hvad der blev vist i brugernes browsere, uden nødvendigvis at være klar over konsekvensen.

Firestore-regler kan forespørge Firebase-data, men ikke Spanner-data, hvilket skabte en hindring for opdateringer af autorisationen, der berørte store virksomhedskundegrupper, som blev synkroniseret via SCIM. SCIM synkroniserer brugere og grupper til et Lovable-arbejdsområde. En midlertidig proxy via Go API’et for erhvervs- og virksomhedskunder genbrugte API’ets adgangskontroller. Den oprettede også separate Firestore-lyttere opstrøms for hver klients afhængigheder, hvilket duplikerede datastrømme og brugte kapacitet i en forbindelsespulje, der blev delt med almindelige databaseforespørgsler.

Lovable krævede, at erstatningen kunne fungere med begge eksisterende databaser, løbende revurdere adgangen og lukke en tilbagekaldt brugers datastrøm midt i en session. Virksomheden ønskede også, at uautoriserede felter blev tilbageholdt, før data forlod serveren. Virksomhedens vurdering var, at de transport-, synkroniserings- og databaseintegrerede løsninger, den evaluerede, ikke kunne levere denne kombination uden omfattende integrationsarbejde, et databaseskift eller replikering til Postgres.

Den resulterende Go-tjeneste kører på GKE og åbner én WebSocket pr. browserfane, hvor abonnementerne multiplekses over forbindelsen. Change data capture-feeds fører ændringer fra Firestore og Spanner gennem en bro til NATS, tjenestens meddelelsesbus. Abonnementer, der matcher, genberegner deres visninger, sammenligner xxh3-128-hashværdier og sender kun ændringer, når resultatet ændres. Ét abonnement kan hente data fra begge databaser og samtidig anvende API’ets tilladelsesrammeværk.

Autorisation behandles som endnu en reaktiv datakilde, så ændringer af tilladelser kan udløse nye resultater uafhængigt af almindelige dokumentredigeringer. Lovable oplyste, at det at genberegne kun, når felter, der indgår i adgangsbeslutninger, blev ændret, i stedet for ved hver relevant dokumentopdatering, reducerede antallet af tilladelsesgenberegninger med cirka 84 %. Tjenesten har omkring 40 abonnementstyper, som ejes af syv teams, med typesikrede grænseflader, delte abonnementer på serversiden og alarmer, der sendes til de relevante teams.

Skyggetrafik validerede udrulningen

Lovable kørte først tjenesten i skyggetilstand: Frontenden gennemgik hele den nye proces, men kasserede dens data og fortsatte med at vise indhold fra Firestore. Brug af faktisk trafik og reelle datastrukturer afslørede storme af genforbindelser efter udrulninger, fejl, der var klassificeret forkert, og en datagrænse, der var for lav til virkelige data. Derefter øgede et funktionsflag gradvist andelen af brugere, der havde adgang, fra 1 % til 10 %, 50 % og 100 % over flere dage. Lovable oplyste, at udrulningen ikke førte til hændelser, der påvirkede brugerne, eller forringelser af de overvågede målinger.

Da WebSocket-forbindelser er fastlåste og kan vare i timevis, flytter det ikke i sig selv den eksisterende belastning at tilføje pods. Lovable fordeler belastningen efter antallet af forbindelser, skalerer ud fra antallet af forbindelser sammen med CPU- og hukommelsesforbruget og begrænser antallet af forbindelser pr. pod for at mindske bølger af genforbindelser. Efter en genforbindelse sender klienterne et fingeraftryk af deres cachede tilstand, så serveren kan bekræfte, at dataene er uændrede efter en ny kontrol af autorisationen, i stedet for at sende dem igen.

Indlæggets forfatter skrev, at kernearbejdet tog 40 arbejdsdage med praktisk udviklingsarbejde, og at kodeagenter stod for det meste af implementeringen, efter at arkitekturen og kanttilfældene var blevet gennemarbejdet. Et integrationsmiljø kombinerede Firestore-, Auth- og Spanner-emulatorer med en indlejret NATS-server og ID-tokens, der var oprettet af en rigtig emulator, så agenterne kunne teste ændringer på tværs af hele stakken.

Resultater i produktion og mulig understøttelse af apps

For perioden fra 5. september til 5. oktober 2026 rapporterede Lovable 2,61 milliarder data- og patchrammer, eksklusive genoptagne kontrolrammer, og anslog, at fulde øjebliksbilleder af hvert beregnet resultat ville have genereret 40 TB applikationsdata. Deduplikering, ændringsdata og genbrug ved genforbindelser reducerede den faktiske mængde sendte data til 1,11 TB, hvilket svarer til en anslået reduktion på 97 % i forhold til dette udgangspunkt. Tallene for datamængder omfatter ikke protokol- og transportoverhead.

Lovable målte intervallet fra en skrivning til kildedatabasen, til en udgående ramme var klar til at blive sendt, til 66 millisekunder ved p50 og 249 millisekunder ved p99. Målingerne omfatter ikke socket-skrivninger, netværkstid eller klientbehandling og repræsenterer derfor ikke den samlede opdateringstid, som brugeren oplever.

Lovable sagde, at virksomheden aktivt tilføjer grundlæggende byggesten til domænehændelser i tilfælde, hvor forbrugerne har brug for at få besked om, at noget er sket, i stedet for at modtage et dataøjebliksbillede, og at tjenesten senere muligvis bliver en funktion i apps, der er bygget med Lovable. En sådan udvidelse ville give kundeskabte applikationer tilladelser, der styres af backend-systemet, og livevisninger. Den nuværende implementering giver allerede Lovables teams et fælles grundlag for et tættere samarbejde, efterhånden som deres datainfrastruktur udvikler sig.