Hört auf, Datenbanken zu bauen

Die Komplexität des Datenmanagements

• Frontend-Ingenieure erkennen, dass sie API-Daten cachen müssen.
• Am Anfang beginnt es mit einfacher Datenspeicherung, aber mit zunehmenden Feature-Anfragen implementiert man Daten-Caches, manuelle Indizes, optimistische Mutationen (optimistic mutations), rekursive Cache-Invalidierung und mehr.
• Diese Funktionen ähneln dem Innenleben einer Datenbank, und in komplexen Frontend-Applikationen baut man am Ende eine domänenspezifische Datenbank.

Die Grundlagen des Cachings

• Es beginnt damit, die Ergebnisse von API-Anfragen in lokalen Variablen zu speichern.
• In Webanwendungen mit deklarativen Frameworks werden Daten in Variablen gespeichert, um unnötige API-Anfragen zu vermeiden.
• Der nächste Schritt ist, den Cache in eine höhere Schicht oder außerhalb des UI-Baums zu verschieben.

Mehr Geschwindigkeit durch Indizes

• Indem man Daten auf bestimmte Weise organisiert, kann man die Arbeit der Anwendung reduzieren und die User Experience verbessern.
• Man stellt fest, dass die Optimierung von Frontend-Daten dem Innenleben eines Datenbank-Storage ähnelt.
• Die Datenstruktur wird verbessert, indem Daten nach ID gespeichert und Indizes erstellt werden, mit denen sich Einträge schnell nach Datum abrufen lassen.

Optimistische Mutationen

• Dabei werden die Effekte bestimmter Aktionen lokal simuliert, ohne auf die Serverantwort zu warten.
• Dadurch wirkt die Benutzeroberfläche sofort reaktionsfähig, aber wenn der Server zu einem anderen Ergebnis kommt, muss die UI die Änderungen zurückrollen.
• Es gibt Herausforderungen wie das Duplizieren der Logik zwischen Client und Server, das Behandeln asynchroner Fehler und das Abgleichen von Änderungen über App-Neustarts hinweg.

Rekursive Cache-Invalidierung

• Daten erscheinen an mehreren Stellen im Cache, und nach einem Update muss der Cache korrekt invalidiert werden, damit er mit dem Server übereinstimmt.
• Die UI muss wissen, welche Teile des Caches zu welcher Mutation gehören, was mit wachsendem Umfang fragil werden kann.
• In Kombination mit optimistischen Mutationen wird es noch schwieriger, Serverlogik auf dem Client zu duplizieren, um Serveränderungen vorherzusagen.

Baut ihr gerade eine Datenbank?

• In Frontend-Applikationen mit genügend Komplexität implementiert man am Ende viele Datenmanagement-Funktionen, was Zeit kostet, die eigentlich dafür gedacht ist, Nutzer glücklich zu machen und Geschäftsprobleme zu lösen.
• Es wird eine Alternative zu einem für das Frontend optimierten Datenbank-Stack vorgestellt.

Einführung in SQLSync

• Es wurde SQLSync entwickelt, ein für das Frontend optimierter Datenbank-Stack auf Basis von SQLite.
• SQLSync wurde dafür entworfen, Probleme beim Datenmanagement zu lösen, damit sich Entwickler auf die einzigartigen Funktionen ihrer Anwendung konzentrieren können.
• SQLSync bietet einen dauerhaften Cache, den vollen Funktionsumfang von SQLite, optimistische Mutationen, intelligente Cache-Invalidierung und reaktive Queries.

Meinung von GN⁺

Das Wichtigste an diesem Artikel ist das Phänomen, dass Entwickler mit zunehmender Komplexität von Frontend-Applikationen am Ende selbst Funktionen implementieren, die einer Datenbank ähneln. Diese Arbeit verbraucht die Zeit der Entwickler und lenkt von der Entwicklung von Funktionen ab, die den Nutzern tatsächlich Mehrwert bieten. Frontend-optimierte Datenbank-Stacks wie SQLSync schlagen einen innovativen Ansatz vor, um dieses Problem zu lösen. Dieser Artikel ist interessant, weil er auf grundlegende Probleme bestehender Datenmanagement-Ansätze hinweist und nach neuen Lösungen sucht, mit denen Entwickler effizienter arbeiten können.

[GN⁺]

Hacker-News-Kommentare

• Verständnis für den Freund, der das Projekt entwickelt hat

  • SQLsync ist ein Tool, mit dem Frontend-Entwickler Remote-Datenbanken direkt im Browser abfragen und aktualisieren können.
  • Es funktioniert, indem es die Leistung von WASM nutzt, um eine SQLite-Datenbank in den Browser zu übertragen.
  • Für die Synchronisierung zwischen mehreren Clients wird ein reaktiver Algorithmus verwendet.
  • Es ist ein Ansatz, der die Datensynchronisierung für Entwickler auf innovative Weise löst.

• Erfahrungen mit Projektmanagement-Software in einem früheren Unternehmen

  • Daten wurden mit einem Check-in/Check-out-Mechanismus synchronisiert, galten mit dem Aufkommen von Apps mit Echtzeit-Updates jedoch als veraltet.
  • Aus der Erfahrung von zehn Jahren beim Aufbau von SPA-Web-Apps wirkt ein solcher Datensynchronisierungsmechanismus seiner Zeit voraus.

• Probleme, die verschwinden, wenn man SPA aufgibt

  • Mit Lösungen wie Hotwire oder htmx werden Serverabfragen vereinfacht, und das Problem, sie schnell zu machen, ist besser verstanden.

• Meinung des SQLSync-Entwicklers

  • Er beantwortet viele Fragen und will regelmäßig nachsehen, welche er verpasst hat.
  • Er freut sich über die Diskussion zum ersten Beitrag, der sich auf die Motivation hinter SQLSync konzentriert.
  • Im nächsten Beitrag will er erklären, wie SQLSync funktioniert.

• Keine mentalen Modelle vermitteln, die nicht der Realität entsprechen

  • Datenbanksynchronisierung kann komplexer sein als ein Client-Server-Modell.
  • Wenn eine schnelle UI nötig ist, erscheint es sicherer, CRDT-Bausteine zu verwenden.

• Das Prinzip, dass Messbares gemanagt wird, und der Fehlschluss der versunkenen Kosten

  • Die Komplexität von Datenbanken ist das Problem.
  • Die SQL-Syntax ist das Problem, und wenn die Nutzung einer einfachen relationalen Datenbank ein angenehmes Erlebnis wäre, wäre die Versuchung größer, einfach eine DB zu verwenden, statt eine eigene Datenbank zu bauen.
  • Gute Datenbanken verwenden SQL, und für Effizienz sollte man eine Datenbanksprache verwenden.

• Das Problem der Zustandssynchronisierung zwischen Client und Server

  • Mit einem PHP-/SSR-Modell kann man das Problem umgehen, indem man UX opfert.
  • SPA ist gut, aber auch mehrteilige Formular-Posts funktionieren weiterhin.
  • Den gesamten Zustand auf dem Server zu halten und den Client als simples Terminal zu behandeln, verbessert die Developer Experience.

• Vergleich mit ORM-Bibliotheken

  • Eine Frage zum Vergleich von SQLsync mit der direkten Nutzung von TypeORM und SQL.js mit Browser-Unterstützung.

• Unterschiede zwischen Frontend- und Backend-Datenbanken

  • Frontend-Datenbanken können sich von Backend-Datenbanken unterscheiden, und auf dem Client muss der Echtzeitzustand möglicherweise besser verwaltet werden.
  • Es wird erwogen, mit react query und WebSockets über Cache-Invalidierung nachzudenken.
  • Auch die Idee von SQLsync ist eine Überlegung wert.

• Ein ähnlicher Versuch mit SignalDB

  • SignalDB nutzt signalbasierte Reaktivität und eine mongodb-ähnliche Query-Syntax, die frameworkunabhängig ist.