Lovable entwickelt Realtime-Dienst als Ersatz für direkte Firestore-Listener
Lovable hat sein Frontend von direkten Firestore-Listenern gelöst und Lovable Realtime entwickelt, einen Go-basierten WebSocket-Dienst, der sowohl die Autorisierung als auch die Aufbereitung der Daten im Backend steuert. Nach Angaben des Unternehmens verarbeitet der Dienst Spitzen von mehr als 2 Millionen parallelen Abonnements und liefert rund 2,6 Milliarden Daten- und Patch-Frames pro Monat aus.
- Lovable hat direkte Firestore-Listener im Frontend durch Lovable Realtime ersetzt.
- Der Go-basierte Dienst bereitet Nutzlasten auf und überprüft die Autorisierung serverseitig neu.
- Er unterstützt Spitzen von mehr als 2 Millionen parallelen Abonnements.
- Der Dienst liefert rund 2,6 Milliarden Daten- und Patch-Frames pro Monat aus.
- Lovable hat ihn ohne einen für Nutzer sichtbaren Vorfall für alle Nutzer ausgerollt.
Warum Lovable sich von Firestore-Listenern verabschiedet hat
Lovable zufolge öffnete die frühere Frontend-Architektur Firestore-onSnapshot-Listener direkt im Browser. Dadurch erhielt der Browser vollständige Firestore-Dokumente, während die Firestore-Regeln das Berechtigungsmodell im Go-Backend des Unternehmens abbilden mussten.
Das schuf ein Risiko, sobald ein Datenbankdokument ein Feld hinzugewann, denn dieses Feld konnte dadurch ebenfalls für den Browser sichtbar werden. Firestore Security Rules konnten außerdem nicht auf Spanner zugreifen. Das wurde bei Berechtigungsänderungen für große Gruppen zum Problem. Lovables SCIM-Funktion synchronisiert Nutzer und Gruppen mit Arbeitsbereichen. Nach Angaben des Unternehmens erfordern diese Vorgänge umfangreiche Datenbanktransaktionen und Abfragemuster, die Dokumentendatenbanken wie Firestore nicht auf demselben Niveau wie Spanner bieten.
Lovable leitete einige Abonnements für Geschäftskunden und Unternehmen vorübergehend über seine Go-API. Der Proxy eröffnete jedoch für die Datenabhängigkeiten jedes Clients eigene Firestore-Listener. Bei Millionen aktiver Abonnements hätte dieser Ansatz nach Angaben des Unternehmens Millionen langlebiger Upstream-Streams erfordert, die häufig wiederholt dieselben Daten überwachen.
Eine vom Backend gesteuerte Realtime-Architektur
Lovable Realtime ist für die Zusammenarbeit mit den bestehenden Firestore- und Spanner-Daten des Unternehmens ausgelegt und erfordert keinen Wechsel zu einer anderen primären Datenbank. Der Dienst überprüft die Autorisierung kontinuierlich neu, solange eine Verbindung geöffnet bleibt. Dadurch kann der Stream eines widerrufenen Nutzers mitten in einer Sitzung geschlossen werden. Das Backend entscheidet außerdem, welche Felder in jeder Nutzlast erscheinen. Felder, auf die ein Aufrufer nicht zugreifen darf, verlassen den Server daher nicht.
Der Dienst verwendet einen WebSocket pro Browser-Tab, über den mehrere Abonnements gebündelt werden. Change Data Capture übermittelt Aktualisierungen aus Firestore und Spanner über eine Bridge an NATS. Wenn eine Nachricht eintrifft, leitet der Dienst sie an passende Abonnement-Instanzen weiter, berechnet jede Datendarstellung neu, entfernt mithilfe eines xxh3-128-Hashs Duplikate und sendet ein Delta an das Frontend, sobald sich die Ausgabe geändert hat.
Der Dienst läuft in Go auf GKE. Nach Angaben von Lovable hält jeder Pod eine NATS-Verbindung und Tausende WebSocket-Verbindungen. NATS bietet hierarchische Wildcard-Subjects und ein interessenbasiertes Cluster-Routing. Nachrichten werden daher an Knoten mit passenden Abonnenten gesendet, statt an jeden Knoten im Cluster verteilt zu werden.
Was das System für Entwickler und Nutzer bedeutet
Lovable zufolge verwenden Entwickler ein Backend-Framework und ein Frontend-SDK. Im Frontend gibt ein Entwickler einen Abonnementnamen und einen Parameter an. Parameter und Nutzlasten sind durchgehend anhand von Go-Strukturen typisiert. Mehrere Komponenten, die dieselben Daten abonnieren, können automatisch ein serverseitiges Abonnement gemeinsam nutzen. Das SDK verwaltet außerdem Wiederverbindungen mit Backoff und Jitter sowie Frames zur Aktualisierung von Authentifizierungstoken.
Im Backend ähnelt eine Abonnementfunktion einem Endpunkt: Sie erhält Parameter, prüft den Zugriff, liest die benötigten Daten und gibt das Antwortobjekt zurück. Das Framework verfolgt, welche Daten von dieser Funktion verwendet werden, und ruft sie erneut auf, wenn sich diese Abhängigkeiten ändern. Nach Angaben von Lovable können dadurch auch Berechtigungsänderungen die Ausgabe eines Abonnements verändern, statt Aktualisierungen auf direkte Datenbankänderungen zu beschränken.
Der Kerndienst wurde in 40 Arbeitstagen mit praktischer Entwicklungsarbeit erstellt und ohne einen für Nutzer sichtbaren Vorfall für alle Nutzer ausgerollt, so Lovable. Ziel des Unternehmens ist es, die Realtime-Auslieferung mit den bestehenden Datenbanken zu verbinden, Berechtigungsentscheidungen zu zentralisieren und die an Browser übermittelten Daten zu reduzieren.
