Lovable tworzy usługę działającą w czasie rzeczywistym, aby scentralizować uprawnienia do danych

Lovable poinformowało 9 listopada 2026 r., że po pełnym wdrożeniu Lovable Realtime jego frontend przestał korzystać z Firestore. Ta niestandardowa usługa centralizuje autoryzację i w szczytowym momencie obsługiwała 2,06 mln równoczesnych subskrypcji w 30-dniowym okresie pomiarowym.

Migracja przenosi decyzje dotyczące dostępu i widocznych pól do backendu Lovable napisanego w Go. W przypadku platformy firmy do tworzenia aplikacji AI usługa umożliwia łączenie danych z Firestore i Spanner oraz aktualizowanie widoku użytkownika, gdy zmienią się dane źródłowe lub uprawnienia tego użytkownika.

Centralizacja uprawnień i danych na żywo

Lovable wcześniej korzystało w niektórych częściach produktu z działających w przeglądarce onSnapshot mechanizmów nasłuchiwania Firestore do odbierania aktualizacji. Przeglądarka otrzymywała całe dokumenty, a reguły Firestore musiały odzwierciedlać model uprawnień interfejsu API Go. W tym rozwiązaniu ujawnianie danych wiązało się też ze zwykłymi zmianami w dokumentach: osoba dodająca pole mogła decydować o tym, jakie dane trafiają do przeglądarek użytkowników, niekoniecznie zdając sobie sprawę z konsekwencji.

Reguły Firestore mogą odpytwać dane Firebase, ale nie Spanner, co utrudniało aktualizowanie autoryzacji dla dużych grup firmowych synchronizowanych za pośrednictwem SCIM, który synchronizuje użytkowników i grupy z obszarem roboczym Lovable. Tymczasowe rozwiązanie pośredniczące, korzystające z interfejsu API Go i przeznaczone dla klientów biznesowych oraz korporacyjnych, ponownie wykorzystywało mechanizmy sprawdzania uprawnień tego interfejsu API. Otwierało też osobne połączenia nasłuchujące Firestore dla zależności każdego klienta, co powodowało duplikowanie strumieni i zużywało zasoby puli połączeń współdzielonej ze zwykłymi żądaniami do bazy danych.

Lovable wymagało, aby zastępcze rozwiązanie współpracowało z obiema używanymi bazami danych, stale ponownie weryfikowało dostęp i zamykało strumień użytkownika, któremu odebrano uprawnienia, nawet w trakcie sesji. Firma chciała też, aby niedozwolone pola były odrzucane, zanim jakiekolwiek dane opuszczą serwer. Według jej oceny rozważane rozwiązania z zakresu transportu danych i synchronizacji oraz opcje zintegrowane z bazą danych nie zapewniały takiego połączenia możliwości bez znacznych prac integracyjnych, zmiany bazy danych lub replikacji danych do Postgresa.

Powstała usługa napisana w Go działa w GKE i otwiera jedno połączenie WebSocket dla każdej karty przeglądarki, a subskrypcje są multipleksowane w ramach tego połączenia. Strumienie przechwytywania zmian przekazują zmiany w Firestore i Spanner przez most do NATS, czyli magistrali komunikatów usługi. Pasujące subskrypcje ponownie obliczają swoje widoki, porównują skróty xxh3-128 i wysyłają delty tylko wtedy, gdy zmienia się wynik. Pojedyncza subskrypcja może pobierać dane z obu baz, stosując jednocześnie mechanizm uprawnień interfejsu API.

Autoryzacja jest traktowana jako kolejne reaktywne źródło danych, dzięki czemu zmiany uprawnień mogą wywoływać ponowne obliczenia wyników niezależnie od zwykłych edycji dokumentów. Lovable poinformowało, że ponowne obliczanie wyników tylko wtedy, gdy zmieniały się pola mające wpływ na decyzje o dostępie, zamiast przy każdej istotnej aktualizacji dokumentu, zmniejszyło liczbę ponownych obliczeń uprawnień o około 84%. Usługa obejmuje około 40 typów subskrypcji zarządzanych przez siedem zespołów, typowane interfejsy, współdzielone subskrypcje po stronie serwera oraz alerty kierowane do zespołów.

Ruch w trybie cienia zweryfikował wdrożenie

Lovable najpierw uruchomiło usługę w trybie cienia: frontend obsługiwał całą nową ścieżkę, ale odrzucał otrzymane dane i nadal renderował widok na podstawie Firestore. Testy na rzeczywistym ruchu i rzeczywistych strukturach danych ujawniły gwałtowne fale ponownych połączeń po wdrożeniach, błędnie sklasyfikowane błędy oraz zbyt niski limit wielkości danych dla rzeczywistych danych. Następnie za pomocą flagi funkcji zwiększano dostępność usługi dla użytkowników przez kilka dni: kolejno z 1% do 10%, 50% i 100%. Lovable poinformowało, że wdrożenie nie spowodowało żadnego incydentu zauważalnego dla użytkowników ani pogorszenia monitorowanych wskaźników.

Ponieważ połączenia WebSocket są trwale przypisane do instancji i mogą działać przez wiele godzin, samo dodawanie podów nie przenosi istniejącego obciążenia. Lovable równoważy obciążenie na podstawie liczby połączeń i skaluje usługę, uwzględniając tę liczbę obok użycia procesora i pamięci. Ogranicza też liczbę połączeń na pod, aby zmniejszyć fale ponownych połączeń. Po ponownym połączeniu klienci wysyłają odcisk stanu zapisanych w pamięci podręcznej danych, dzięki czemu serwer może po ponownej weryfikacji uprawnień potwierdzić, że dane się nie zmieniły, zamiast przesyłać je ponownie.

Autor wpisu poinformował, że prace nad podstawową częścią rozwiązania zajęły 40 dni roboczych pracy praktycznej, a agenci kodujący wykonali większość implementacji po opracowaniu architektury i przeanalizowaniu przypadków brzegowych. Zestaw do testów integracyjnych łączył emulatory Firestore, Auth i Spanner z osadzonym serwerem NATS oraz rzeczywistymi tokenami ID wygenerowanymi przez emulatory, dzięki czemu agenci mogli testować zmiany w całym stosie.

Wyniki produkcyjne i perspektywy obsługi aplikacji

Za okres od 5 września do 5 października 2026 r. Lovable podało, że przesłano 2,61 mld ramek danych i poprawek, z wyłączeniem wznowionych ramek sterujących. Firma oszacowała, że wysłanie pełnych migawek dla każdego obliczonego wyniku wygenerowałoby 40 TB danych aplikacyjnych. Dzięki deduplikacji, deltą i ponownemu wykorzystywaniu danych przy wznowieniu połączeń rzeczywiście przesłano 1,11 TB, co oznacza szacowany spadek o 97% względem tej wartości bazowej. Podane wielkości danych nie uwzględniają narzutu protokołu ani transportu.

Lovable zmierzyło czas od zapisu w źródłowej bazie danych do chwili, gdy wychodząca ramka była gotowa do wysłania: wyniósł on 66 milisekund przy p50 i 249 milisekund przy p99. Pomiary te nie obejmują zapisu do gniazda, czasu przesyłania przez sieć ani przetwarzania po stronie klienta, więc nie odzwierciedlają całkowitego czasu aktualizacji odczuwanego przez użytkownika.

Lovable poinformowało, że aktywnie dodaje podstawowe mechanizmy obsługi zdarzeń domenowych na potrzeby sytuacji, w których odbiorcy muszą otrzymać informację o tym, że coś się wydarzyło, zamiast jedynie migawki danych, a także że usługa może później stać się funkcją dostępną w aplikacjach tworzonych za pomocą Lovable. Takie rozszerzenie zapewniłoby aplikacjom tworzonym przez klientów uprawnienia kontrolowane przez backend oraz widoki aktualizowane na bieżąco. Obecne wdrożenie już teraz zapewnia zespołom Lovable wspólną podstawę do bogatszej współpracy w miarę rozwoju ich infrastruktury danych.