Lovable bouwt realtime dienst om gegevensmachtigingen te centraliseren

Lovable meldde op 9 november 2026 dat zijn frontend volledig was overgestapt van Firestore met de volledige uitrol van Lovable Realtime, een aangepaste dienst die autorisatie centraliseert en tijdens een meetperiode van 30 dagen een piek van 2,06 miljoen gelijktijdige abonnementen bereikte.

Door de migratie worden beslissingen over toegang en zichtbare velden genomen in de Go-backend van Lovable. Voor het AI-platform van het bedrijf waarmee apps worden gebouwd, biedt de dienst één manier om gegevens uit Firestore en Spanner te combineren en de weergave voor een gebruiker bij te werken wanneer de onderliggende informatie of de machtigingen van die gebruiker veranderen.

Machtigingen en livegegevens centraliseren

Voorheen maakten onderdelen van Lovable gebruik van Firestore in de browser onSnapshot voor updates via listeners. De browser ontving volledige documenten, terwijl de regels van Firestore het machtigingenmodel van de Go-API moesten weerspiegelen. Door deze opzet werd het blootstellen van gegevens ook onderdeel van gewone documentwijzigingen: iemand die een veld toevoegde, kon bepalen welke gegevens in de browsers van gebruikers terechtkwamen, zonder zich noodzakelijkerwijs van dat gevolg bewust te zijn.

Met de regels van Firestore kunnen Firebase-gegevens worden opgevraagd, maar geen gegevens uit Spanner. Dat vormde een belemmering voor autorisatie-updates voor grote bedrijfsgroepen die via SCIM werden gesynchroniseerd; SCIM synchroniseert gebruikers en groepen met een Lovable-werkruimte. Een tijdelijke proxy via de Go-API voor zakelijke en enterprise-klanten hergebruikte de machtigingscontroles van de API. Deze opende ook afzonderlijke upstream Firestore-listeners voor de afhankelijkheden van elke client, waardoor gegevensstromen werden gedupliceerd en capaciteit werd verbruikt in een verbindingspool die werd gedeeld met gewone databaseverzoeken.

Lovable eiste dat de vervangende oplossing met beide bestaande databases zou werken, de toegang voortdurend opnieuw zou beoordelen en de gegevensstroom van een gebruiker van wie de toegang was ingetrokken midden in een sessie zou afsluiten. Ook wilde het bedrijf dat onbevoegde velden werden achtergehouden voordat er gegevens de server verlieten. Volgens de beoordeling van het bedrijf boden de geëvalueerde opties voor transport, synchronisatie en integratie met databases deze combinatie niet zonder omvangrijk integratiewerk, een wijziging van de database of replicatie naar Postgres.

De resulterende Go-dienst draait op GKE en opent één WebSocket per browsertabblad, waarbij abonnementen via die verbinding worden gebundeld. Feeds voor wijzigingsregistratie voeren wijzigingen in Firestore en Spanner via een brug naar NATS, de berichtenbus van de dienst. Overeenkomende abonnementen berekenen hun weergaven opnieuw, vergelijken xxh3-128-hashes en versturen alleen delta’s wanneer de uitvoer verandert. Eén abonnement kan gegevens uit beide databases ophalen en daarbij het machtigingenkader van de API toepassen.

Autorisatie wordt behandeld als een andere reactieve gegevensbron, zodat machtigingswijzigingen onafhankelijk van gewone documentbewerkingen nieuwe resultaten kunnen opleveren. Lovable meldde dat het opnieuw berekenen alleen wanneer velden veranderden die betrokken waren bij toegangsbeslissingen, in plaats van bij elke relevante documentupdate, het aantal machtigingsherberekeningen met ongeveer 84% verminderde. De dienst heeft ongeveer 40 abonnementstypen, die worden beheerd door zeven teams, met getypeerde interfaces, gedeelde abonnementen aan de serverzijde en waarschuwingen die naar teams worden doorgestuurd.

De uitrol gevalideerd met schaduwverkeer

Lovable draaide de dienst eerst in de schaduwmodus: de frontend doorliep het volledige nieuwe traject, maar verwierp de gegevens en bleef de inhoud vanuit Firestore weergeven. Door echt verkeer en echte gegevensstructuren te gebruiken, kwamen verbindingsstormen na implementaties, verkeerd geclassificeerde fouten en een te kleine limiet voor de hoeveelheid gegevens aan het licht. Vervolgens verhoogde een functievlag de beschikbaarheid in enkele dagen van 1% naar 10%, 50% en 100% van de gebruikers. Lovable zei dat de uitrol geen incidenten voor gebruikers en geen verslechtering van de gemonitorde meetwaarden tot gevolg had.

Omdat WebSocket-verbindingen vast aan een server gekoppeld zijn en uren kunnen blijven bestaan, verplaatst het toevoegen van pods de bestaande belasting niet vanzelf. Lovable verdeelt de belasting op basis van het aantal verbindingen, schaalt op basis van zowel verbindingen als CPU en geheugen, en stelt een maximum in voor het aantal verbindingen per pod om golven van nieuwe verbindingen te beperken. Nadat ze opnieuw verbinding hebben gemaakt, sturen clients een vingerafdruk van hun gecachte status. Zo kan de server na een nieuwe autorisatiecontrole bevestigen dat de gegevens ongewijzigd zijn, zonder ze opnieuw te versturen.

De auteur van het bericht zei dat de kern 40 werkdagen aan hands-on werk vergde en dat codeeragenten het grootste deel van de implementatie voor hun rekening namen, nadat de architectuur en randgevallen waren uitgewerkt. Een integratieopstelling combineerde Firestore-, Auth- en Spanner-emulators met een ingebedde NATS-server en ID-tokens die door een echte emulator waren aangemaakt, zodat de agenten wijzigingen in de volledige stack konden testen.

Productieresultaten en mogelijke ondersteuning voor apps

Voor de periode van 5 september tot en met 5 oktober 2026 meldde Lovable 2,61 miljard gegevens- en patchframes, exclusief hervatte besturingsframes. Het bedrijf schatte dat volledige momentopnamen van elk berekend resultaat 40 TB aan applicatiegegevens zouden hebben gegenereerd. Dankzij deduplicatie, delta’s en hergebruik na opnieuw verbinden daalde de daadwerkelijk verzonden hoeveelheid gegevens tot 1,11 TB, naar schatting 97% minder dan die uitgangswaarde. De cijfers over de hoeveelheid gegevens omvatten geen protocol- en transportoverhead.

Lovable mat het interval tussen een schrijfactie in de brondatabase en het moment waarop een uitgaand frame klaarstond om te worden verzonden: 66 milliseconden bij p50 en 249 milliseconden bij p99. Deze metingen omvatten geen socketbewerkingen, netwerktijd of verwerking door de client en geven dus niet de volledige tijd weer die een gebruiker ervaart voordat een update zichtbaar is.

Lovable zei dat het actief basisvoorzieningen voor domeingebeurtenissen toevoegt voor situaties waarin afnemers moeten weten dat er iets is gebeurd, in plaats van een momentopname van gegevens te ontvangen. Ook zei het dat de service later mogelijk een functionaliteit wordt binnen apps die met Lovable zijn gebouwd. Zo’n uitbreiding zou backendgestuurde toegangsrechten en liveweergaven beschikbaar maken in applicaties die door klanten zijn gemaakt. De huidige implementatie biedt de teams van Lovable nu al een gedeelde basis voor intensievere samenwerking, naarmate hun gegevensinfrastructuur zich ontwikkelt.