Lovable rakentaa reaaliaikaisen palvelun keskittämään datan käyttöoikeuksien hallinnan

Lovable kertoi 9. marraskuuta 2026, että sen käyttöliittymä oli siirtynyt pois Firestoresta, kun Lovable Realtime -palvelu otettiin kokonaisuudessaan käyttöön. Mukautettu palvelu keskittää käyttöoikeuksien hallinnan, ja sen huippukuormitus oli 2,06 miljoonaa samanaikaista tilausta 30 päivän mittausjakson aikana.

Siirtymän myötä käyttöoikeuksia ja käyttäjille näkyviä kenttiä koskevat päätökset tehdään Lovablen Go-taustajärjestelmässä. Tekoälysovellusten rakentamiseen tarkoitetulla alustalla palvelu tarjoaa yhden tavan yhdistää Firestore- ja Spanner-dataa sekä päivittää käyttäjän näkymää, kun joko taustalla olevat tiedot tai käyttäjän käyttöoikeudet muuttuvat.

Käyttöoikeuksien ja reaaliaikaisen datan keskittäminen

Osa Lovablesta käytti aiemmin selainpohjaista Firestorea. onSnapshot päivitysten kuunteluun. Selain vastaanotti kokonaisia dokumentteja, ja Firestoren sääntöjen oli vastattava Go-rajapinnan käyttöoikeusmallia. Ratkaisussa tietojen näkyminen riippui myös dokumenttien tavanomaisista muutoksista: kentän lisääjä saattoi vaikuttaa siihen, mitä käyttäjien selaimissa näkyi, huomaamatta välttämättä tämän seurauksia.

Firestore-säännöillä voi tehdä kyselyjä Firebase-dataan mutta ei Spanneriin, mikä vaikeutti suuria yritysryhmiä koskevien käyttöoikeusmuutosten toteuttamista. Ryhmät synkronoitiin SCIMin avulla Lovable-työtilaan; SCIM synkronoi käyttäjät ja ryhmät. Yritys- ja yritysasiakkaille käytetty väliaikainen Go-rajapinnan kautta kulkeva välityspalvelin hyödynsi rajapinnan käyttöoikeustarkistuksia. Se avasi myös erilliset Firestore-kuuntelijat kunkin asiakkaan tarvitsemille tiedoille, mikä monisti tietovirtoja ja kulutti kapasiteettia yhteyspoolista, jota käytettiin myös tavallisiin tietokantapyyntöihin.

Lovable edellytti, että korvaava ratkaisu toimii molempien käytössä olevien tietokantojen kanssa, tarkistaa käyttöoikeudet jatkuvasti uudelleen ja katkaisee käyttöoikeutensa menettäneen käyttäjän tietovirran kesken istunnon. Yhtiö halusi myös estää luvattomien kenttien lähettämisen palvelimelta. Yhtiön arvion mukaan sen tarkastelemat tiedonsiirto-, synkronointi- ja tietokantaan integroidut vaihtoehdot eivät tarjonneet tätä yhdistelmää ilman huomattavaa integrointityötä, tietokannan vaihtamista tai tietojen replikointia Postgresiin.

Tuloksena syntynyt Go-palvelu toimii GKE:ssä ja avaa yhden WebSocket-yhteyden selainvälilehteä kohti. Tilaukset kulkevat monistettuina saman yhteyden kautta. Muutosdatan kaappausvirrat välittävät Firestoren ja Spannerin muutokset NATS-viestinvälitysjärjestelmään yhdyskäytävän kautta. Tilausten näkymät lasketaan uudelleen, kun niiden ehdot täyttyvät; tämän jälkeen järjestelmä vertaa xxh3-128-tiivisteitä ja lähettää muutokset vain, jos tulos on muuttunut. Yksittäinen tilaus voi hakea tietoja molemmista tietokannoista ja soveltaa samalla rajapinnan käyttöoikeuskehystä.

Käyttöoikeuksia käsitellään toisena reaktiivisena tietolähteenä, joten niiden muutokset voivat käynnistää uusien tulosten laskennan riippumatta tavallisista dokumenttimuutoksista. Lovable kertoi, että käyttöoikeuksien uudelleenlaskenta väheni noin 84 prosenttia, kun se käynnistettiin vain käyttöoikeuspäätöksiin vaikuttavien kenttien muuttuessa kaikkien olennaisten dokumenttipäivitysten sijaan. Palvelussa on noin 40 tilaustyyppiä, joista vastaa seitsemän tiimiä. Käytössä ovat tyypitetyt rajapinnat, jaetut palvelinpuolen tilaukset ja tiimeille reititetyt hälytykset.

Varjoliikenne varmisti käyttöönoton

Lovable käytti palvelua ensin varjotilassa: käyttöliittymä kulki koko uuden käsittelypolun läpi mutta hylkäsi palvelun lähettämät tietosisällöt ja jatkoi näkymien renderöintiä Firestoresta. Todellisen liikenteen ja datarakenteiden käyttö paljasti käyttöönottojen jälkeiset uudelleenyhdistämisryöpyt, väärin luokitellut virheet ja todelliselle datalle liian pienen tietosisällön kokorajan. Sen jälkeen ominaisuuslipulla saatavuutta kasvatettiin usean päivän aikana yhdestä prosentista 10 prosenttiin, 50 prosenttiin ja lopulta 100 prosenttiin käyttäjistä. Lovablen mukaan käyttöönotto ei aiheuttanut käyttäjille näkyviä häiriöitä eikä heikentänyt seurattuja mittareita.

Koska WebSocket-yhteydet pysyvät sidottuina samaan palvelimeen ja voivat kestää tuntikausia, palvelinpodien lisääminen ei itsessään siirrä olemassa olevaa kuormaa. Lovable tasaa kuormaa yhteyksien määrän perusteella, skaalaa palvelua yhteyksien määrän, suorittimen käytön ja muistin käytön mukaan sekä rajoittaa podikohtaisia yhteysmääriä uudelleenyhdistämisaaltojen hillitsemiseksi. Uudelleenyhdistämisen jälkeen asiakkaat lähettävät sormenjäljen välimuistissa olevasta tilastaan. Näin palvelin voi käyttöoikeudet uudelleen tarkistettuaan varmistaa tietojen olevan ennallaan ja jättää ne lähettämättä uudelleen.

Kirjoituksen laatijan mukaan ydinosan toteuttaminen vei 40 täyttä työpäivää. Koodausagentit hoitivat suurimman osan toteutuksesta sen jälkeen, kun arkkitehtuuri ja poikkeustapaukset oli selvitetty. Integrointitestipenkki yhdisti Firestore-, Auth- ja Spanner-emulaattorit upotettuun NATS-palvelimeen sekä emulaattorin luomiin oikeisiin ID-tunnisteisiin. Näin agentit pystyivät testaamaan muutoksia koko ohjelmistopinon läpi.

Tuotantotulokset ja mahdollinen tuki sovelluksille

Lovablen mukaan 5. syyskuuta – 5. lokakuuta 2026 palvelu välitti 2,61 miljardia data- ja korjauskehystä, jatkettuja yhteyksiä koskevia ohjauskehyksiä lukuun ottamatta. Yhtiö arvioi, että jokaisen lasketun tuloksen täydet tilannevedokset olisivat tuottaneet sovelluskuormaa 40 Tt. Dedupikointi, muutosten lähettäminen ja välimuistin uudelleenkäyttö yhteyden palautuessa pienensivät todellisuudessa lähetetyn tietosisällön määrän 1,11 Tt:uun eli arviolta 97 prosenttia vertailutasoa pienemmäksi. Tietosisältöä koskevat luvut eivät sisällä protokolla- ja siirtokerroksen ylimääräistä kuormaa.

Lovable mittasi ajan lähdetietokantaan tehdystä kirjoituksesta lähtevän kehyksen lähetysvalmiuteen: p50 oli 66 millisekuntia ja p99 249 millisekuntia. Mittauksiin eivät sisälly socket-kirjoitukset, verkon viive tai asiakkaan suorittama käsittely, joten ne eivät kuvaa käyttäjän kokemaa päivityksen kokonaiskestoa.

Lovable kertoi lisäävänsä parhaillaan toimialuetapahtumien perusmekanismeja tilanteisiin, joissa tiedon käyttäjien on saatava ilmoitus tapahtuneesta yksittäisen tietotilannekuvan sijaan. Se kertoi myös, että palvelusta voisi myöhemmin tulla Lovablella rakennettuihin sovelluksiin sisältyvä ominaisuus. Tällainen laajennus toisi taustajärjestelmän hallitsemat käyttöoikeudet ja reaaliaikaiset näkymät asiakkaiden luomiin sovelluksiin. Nykyinen käyttöönotto tarjoaa jo Lovablen tiimeille yhteisen perustan entistä monipuolisemmalle yhteistyölle niiden datainfrastruktuurin kehittyessä.