Lovable bygger sanntidstjeneste for å samle datatilganger på ett sted

Lovable rapporterte 9. november 2026 at frontendløsningen var flyttet bort fra Firestore etter full utrulling av Lovable Realtime, en spesialutviklet tjeneste som samler autorisasjonen på ett sted, og som nådde en topp på 2,06 millioner samtidige abonnementer i løpet av en måleperiode på 30 dager.

Migreringen legger beslutninger om tilgang og synlige felt til Lovables Go-bakende. For selskapets plattform for AI-apputvikling gir tjenesten én måte å kombinere data fra Firestore og Spanner på og oppdatere brukerens visning når enten den underliggende informasjonen eller brukerens tillatelser endres.

Samling av tillatelser og sanntidsdata på ett sted

Deler av Lovable brukte tidligere Firestore-lyttere i nettleseren onSnapshot for å motta oppdateringer. Nettleseren mottok hele dokumenter, samtidig som Firestore-reglene måtte speile tillatelsesmodellen til Go-API-et. Løsningen gjorde også eksponering til en del av de vanlige dokumentendringene: En person som la til et felt, kunne dermed avgjøre hva som ble sendt til brukernes nettlesere uten nødvendigvis å være klar over konsekvensen.

Firestore-reglene kan spørre etter Firebase-data, men ikke Spanner-data. Dette skapte et hinder for oppdateringer av autorisasjon som berørte store virksomhetsgrupper, synkronisert via SCIM, som synkroniserer brukere og grupper til et Lovable-arbeidsområde. En midlertidig proxy gjennom Go-API-et for bedrifts- og storkunder gjenbrukte API-ets tillatelseskontroller. Den opprettet også separate Firestore-lyttere oppstrøms for hver klients avhengigheter, noe som dupliserte datastrømmer og brukte kapasitet i en tilkoblingspool som også ble delt med vanlige databaseforespørsler.

Lovable krevde at erstatningen skulle fungere med begge de eksisterende databasene, kontinuerlig vurdere tilgangen på nytt og stenge strømmen til en bruker som hadde fått tilbakekalt tilgangen, midt i en økt. Selskapet ønsket også at felt brukeren ikke hadde tilgang til, skulle holdes tilbake før data forlot serveren. Selskapets vurdering var at alternativene for transport, synkronisering og databaseintegrasjon som det evaluerte, ikke tilbød denne kombinasjonen uten omfattende integrasjonsarbeid, bytte av database eller replikering til Postgres.

Den ferdige Go-tjenesten kjører på GKE og åpner én WebSocket per nettleserfane, med abonnementer som deler samme tilkobling. Strømmer for endringsdatafangst fører endringer i Firestore og Spanner via en bro til NATS, tjenestens meldingsbuss. Abonnementer som samsvarer med endringene, beregner visningene sine på nytt, sammenligner xxh3-128-hasher og sender bare differanser når resultatet endres. Ett abonnement kan hente data fra begge databasene og samtidig anvende API-ets tillatelsesrammeverk.

Autorisasjon behandles som en annen reaktiv datakilde, slik at endringer i tillatelser kan utløse nye resultater uavhengig av vanlige dokumentendringer. Lovable rapporterte at det å bare beregne tillatelser på nytt når felt som inngikk i tilgangsbeslutningene, ble endret, i stedet for ved hver relevante dokumentoppdatering, reduserte antallet nye tillatelsesberegninger med omtrent 84 %. Tjenesten har rundt 40 abonnementstyper som eies av sju team, med typede grensesnitt, delte abonnementer på serversiden og varsler rutet til teamene.

Skyggetrafikk validerte utrullingen

Lovable kjørte først tjenesten i skyggekjøringsmodus: Frontendløsningen brukte hele den nye dataflyten, men forkastet nyttelastene og fortsatte å gjengi innhold fra Firestore. Bruk av faktisk trafikk og faktiske datastrukturer avdekket en bølge av gjenoppkoblinger etter utrullinger, feilklassifiserte feil og en nyttelastgrense som var for lav for reelle data. Deretter økte et funksjonsflagg tilgjengeligheten fra 1 % til 10 %, 50 % og 100 % av brukerne over flere dager. Lovable opplyste at utrullingen ikke førte til noen hendelse som berørte brukerne, eller noen tilbakegang i måleverdiene selskapet overvåket.

Fordi WebSocket-tilkoblinger er vedvarende og kan vare i flere timer, flyttes ikke den eksisterende belastningen bare ved å legge til flere podder. Lovable fordeler belastningen etter antall tilkoblinger, skalerer ut fra antall tilkoblinger sammen med CPU- og minnebruk og setter en øvre grense for antall tilkoblinger per pod for å begrense bølger av gjenoppkoblinger. Etter gjenoppkobling sender klientene et fingeravtrykk av den bufrede tilstanden sin. Da kan serveren, etter å ha kontrollert autorisasjonen på nytt, bekrefte at dataene er uendret i stedet for å sende dem på nytt.

Forfatteren av innlegget sa at kjernen krevde 40 dager med aktivt arbeid, og at kodeagenter sto for det meste av implementeringen etter at arkitekturen og kanttilfellene var gjennomarbeidet. Et integrasjonsoppsett kombinerte emulatorer for Firestore, Auth og Spanner med en innebygd NATS-server og ekte ID-tokener utstedt av emulatorene, slik at agentene kunne teste endringer gjennom hele stakken.

Resultater i produksjon og mulig støtte for apper

For perioden fra 5. september til 5. oktober 2026 rapporterte Lovable 2,61 milliarder data- og patchrammer, unntatt gjenopptatte kontrollrammer, og anslo at fullstendige øyeblikksbilder av hvert beregnede resultat ville ha generert 40 TB med nyttelast for applikasjonen. Deduplisering, differanser og gjenbruk etter gjenoppkobling reduserte den faktiske sendte nyttelasten til 1,11 TB, en anslått reduksjon på 97 % fra dette utgangspunktet. Tallene for nyttelast omfatter ikke protokoll- og transportoverhead.

Lovable målte tidsrommet fra en skriving til kildedatabasen til en utgående ramme var klar til å sendes, til 66 millisekunder ved p50 og 249 millisekunder ved p99. Målingene omfatter ikke skriving til sokkelen, nettverkstiden eller klientbehandlingen, og representerer derfor ikke hele oppdateringstiden slik brukeren opplever den.

Lovable sa at selskapet aktivt legger til grunnleggende byggesteiner for domenebegivenheter i tilfeller der konsumenter trenger beskjed om at noe har skjedd, i stedet for et øyeblikksbilde av dataene, og at tjenesten senere kan bli en funksjon i apper som bygges med Lovable. En slik utvidelse ville gi kundeskapte apper backendstyrte tillatelser og sanntidsvisninger. Den nåværende utrullingen gir allerede Lovables team et felles grunnlag for rikere samarbeid etter hvert som datainfrastrukturen deres utvikler seg.