InstantDB – „modernes Firebase“: Open-Source-Echtzeit-Datenbank für den Client

• Eine clientseitige Datenbank, mit der sich Echtzeit-Kollaborations-Apps wie Notion oder Figma einfach entwickeln lassen
• Schreibt man relationale Abfragen, übernimmt Instant das Abrufen der Daten, die Prüfung von Berechtigungen und das Offline-Caching
• Bei Datenänderungen werden auch Optimistic Updates und Rollbacks automatisch verarbeitet
• Alle Abfragen unterstützen standardmäßig Multiplayer
• Unterstützt auch flüchtige Updates wie Cursor oder Online-Status
• Bietet derzeit SDKs für Javascript, React und React Native

Motivation für die Entwicklung

• Moderne App-Entwicklung erfordert viel Arbeit wie Server-Setup, Datenbank, Cache, ORM und Endpoint-Konfiguration
• Außerdem müssen clientseitiger Code, State Management und UI-Rendering umgesetzt werden
• Fügt man Multiplayer-Funktionen hinzu, muss man über einen zustandsbehafteten Server nachdenken, und für Offline-Unterstützung über IndexedDB und Transaktionswarteschlangen
• Bei jeder neuen Funktion müssen Modell, Endpoints, State Management und UI immer wieder neu geschrieben werden
• 2021 wurde klar, dass die meisten Probleme, mit denen UI-Engineers konfrontiert sind, in Wirklichkeit Datenbankprobleme sind
• Mit einer clientseitigen Datenbank muss man nur Abfragen schreiben, ohne über State Management, Endpoints oder lokalen Cache nachdenken zu müssen
• Wenn Abfragen standardmäßig Multiplayer unterstützen, muss man sich keine Gedanken über einen zustandsbehafteten Server machen
• Wenn die Datenbank Rollbacks unterstützt, bekommt man Optimistic Updates praktisch gratis
• Deshalb wurde Instant entwickelt. Instant stellt eine Datenbank bereit, die auf dem Client genutzt werden kann, damit man sich auf den Aufbau der UX konzentrieren kann

Architekturüberblick

• Instant speichert alle Nutzerdaten als Tripel in einer einzigen großen Postgres-Datenbank
• Durch ein Multi-Tenant-Setup wird ein Free Tier angeboten
• Ein in Clojure geschriebener Sync-Server kommuniziert mit Postgres
• Es wurde eine Query Engine entwickelt, die InstaQL versteht, das Datalog und GraphQL ähnelt
• Inspiriert von Asanas WorldStore und Figmas LiveGraph werden die WALs von Postgres verfolgt, um neue Daten zu erkennen und relevante Abfragen zu invalidieren
• Im Frontend wurde ein clientseitiger Triple Store entwickelt
• Das SDK speichert den jüngsten Query-Cache im Web in IndexedDB und in React Native in AsyncStorage
• Alle Daten werden über ein Berechtigungssystem verarbeitet, das von Google's CEL-Bibliothek angetrieben wird

Zusammenfassung von GN⁺

• Instant ist eine clientseitige Datenbank, mit der sich Echtzeit-Kollaborations-Apps einfach entwickeln lassen
• Über relationale Abfragen werden Datenabruf, Berechtigungsprüfung und Offline-Caching automatisch verarbeitet
• Multiplayer-Funktionen, Optimistic Updates und Rollbacks werden standardmäßig unterstützt
• Inspiriert von Asana und Figma werden die WALs von Postgres verfolgt, um neue Daten zu erkennen und relevante Abfragen zu invalidieren
• Über einen clientseitigen Triple Store und ein Berechtigungssystem wird das Datenmanagement effizient verarbeitet

[stargt]

Das ist wirklich ein Projekt, auf das man sich freuen kann, ähnlich wie Supabase.

[GN⁺]

Hacker-News-Kommentare

• Firebase-Gründer: Begeistert von Instants Kombination aus Offline-, Echtzeit-, relationalen Abfragen und Open Source. Es gab viele Anfragen nach relationalen Abfragen. Der Firebase-Client ist Open Source, aber das Open-Sourcing des Backends ist gescheitert

• Feedback: Die Codebeispiele sind nicht vollständig. Die Herkunft von transact und useQuery ist nicht klar. Kleine Details sind wichtig

• Möglichkeit zum Self-Hosting: Teile des Tools lassen sich oft nicht selbst hosten. Das sollte klarer kommuniziert werden

• Alternative zum Offline-First-Modell: PowerSync wurde gewählt. WatermelonDB ist ebenfalls in Ordnung. ElectricSQL ist noch unreif. CouchDB und PocketDB sind nicht modern. PowerSync und Supabase sollen als Backend verwendet werden

• Bezug zu CRUD-Apps: Es ist schwer zu verstehen, wie CRUD-Apps zu den Konzepten von InstantDB oder Firebase stehen. Für kollaborative Texteditoren würde eine CRDT-JavaScript-Implementierung verwendet werden

• Erfahrungen mit Instant: Instant wurde 6 Monate lang verwendet und die Erfahrung war zufriedenstellend. Echtzeit-, relationale und Offline-Funktionen waren wichtig. Andere Tools wurden ausprobiert, scheiterten aber. Seit Instant werden keine anderen Tools mehr verwendet

• Zusammenfassung des Berechtigungssystems: Firebase trennt die Logik für das Abrufen/Aktualisieren von Daten von den Zugriffsrichtlinien. Instant bewertet die Berechtigungslogik anhand der Abfrageergebnisse. Firebase prüft die Sicherheit vor der Ausführung der Abfrage

• Offenlegung der Datalog-Engine: Es gibt andere Datalog-Engines, die rekursive Abfragen unterstützen. Gefragt wird nach Query-Caching und der Möglichkeit von Joins. In der Vergangenheit gab es bereits eine Java-InstantDB mit demselben Namen. Außerdem wird eine Liste anderer in Clojure implementierter Datalog-Engines gegeben

  • Datomic
  • XTDB
  • Datascript
  • Datalevin
  • datahike
  • Naga

• Wunsch nach einer ActiveRecord-ähnlichen Erfahrung: In React/Vue/Solid soll auf eine ActiveRecord-ähnliche Weise gearbeitet werden. Gewünscht ist eine API wie ein Objektgraph. Eine SQL-ähnliche API ist nicht gewünscht. Das ORM soll so arbeiten, als läge der gesamte Objektgraph im Speicher vor

• Leistungsprobleme von Triple Stores: Triple Stores sind oft leistungsschwach, wenn die meisten Abfragen das gesamte Objekt oder mehrere Felder desselben Objekts abrufen. Auch Postgres ist darin nicht besonders stark. Es wird nach Erfahrungen dazu gefragt