- State-Management-Datenschicht, entwickelt, um die Entwicklung von Synchronisationslogik abzunehmen und so die Entwicklung hochperformanter Anwendungen zu ermöglichen
- Charakteristisch ist die Nutzung von reaktivem SQLite und einer integrierten Synchronisations-Engine
- Local-first und damit auch offline mit hoher Performance nutzbar; bei Wiederherstellung der Netzwerkverbindung wird die Synchronisation automatisch unterstützt
- Alle State-Management-Operationen werden schnell auf einer lokalen SQLite-Datenbank ausgeführt
- Reaktive Datenströme: Bei Datenänderungen werden sofort Events an mit der UI verbundene Listener ausgelöst, sodass Statusänderungen in Echtzeit übernommen werden können
- In verschiedenen Umgebungen einsetzbar, darunter Web, Mobile und Desktop
- Im Vergleich zu bestehenden State-Management-Tools bietet es überlegene Ergebnisse bei nativer Performance und Datenkonsistenz
2 Kommentare
Die Demo auf der Startseite ist wirklich sehr gut gemacht. Wenn man ein bisschen darauf herumklickt, bekommt man direkt Lust, es auszuprobieren.
Hacker-News-Kommentare
Hallo, ich bin Mitgründer von LiveStore (zuvor habe ich Prisma entwickelt).
In den letzten vier Jahren habe ich beim Bau von Overtone, einem nativen Hochleistungs-Musikclient, LiveStore für den Eigenbedarf entwickelt.
LiveStore fügt SQLite eine reaktive Signal-Schicht hinzu und kombiniert das mit einer event-sourcing-basierten Sync-Engine (ähnlich wie Git)
Ich habe viele Local-First-Ansätze evaluiert, aber kaum eine Lösung gefunden, die das so sauber löst wie LiveStore
Ein ähnlich reifes Tool ist tinyBase, aber das ist strukturell anders (CRDTs vs. Event Sourcing)
Ich habe eine Frage dazu, warum das Datenvolumen auf 1 GB begrenzt ist und ob es nicht eine Option geben könnte, größere Datenmengen in SQLite zu speichern und auf der Festplatte zu behalten
Könnte man den Persistenzmodus nicht einfach per Konfiguration umschalten?
Multitenancy scheint mir ebenfalls ein interessantes Szenario zu sein: Wenn wie bei JIRA jede Organisation einen separaten Namespace braucht, wäre es gut, wenn jeder Benutzer statt aller Tickets nur die seines Teams bzw. seiner Abteilung erhalten könnte
Im Grunde wäre die lokale Datenbank dann eine Teilmenge der Gesamtdaten. Ein Sync-Server, der direkt unter Bun/Node läuft (ohne Cloudflare), wäre direkt out of the box wirklich großartig
Das würde auch sehr gut zu einer Projektidee passen, die ich gerade prüfe, insbesondere weil Multitenancy dort zwingend erforderlich ist
Letzten Monat habe ich nachgeschaut, ob ich LiveStore für ein Hobbyprojekt verwenden kann, aber als Beta-Preview war der Zugang schwierig
Ich hoffe, es bald genauer anschauen zu können. Beeindruckend ist, wie aktiv ihr die Diskussion rund um Local-First vorantreibt
Wer schon einmal eine offline-synchronisierbare Web-App gebaut hat, erkennt den Nutzen einer Sync-Engine sofort
Ich habe euren Vortrag heute auf der Local-First Conf wirklich gern verfolgt
Die Erklärung der Architektur, die Event Sourcing mit SQLite umsetzt, war klar und überzeugend
Danke auch dafür, dass ihr SQLite, insbesondere OPFS Wasm SQLite, im Web so aktiv bekannt macht
PowerSync steht ebenfalls klar hinter SQLite, daher sind Erfolgsgeschichten wie LiveStore sehr erfreulich
Wenn LiveStore das Event-Sourcing-Modell global skaliert, erfolgt die Synchronisation aller Clients üblicherweise über ein zentrales Sync-Backend. Mich würde interessieren, ob das zwingend erforderlich ist
Wären eventuell auch föderierte Nodes oder ein vollständiger P2P-Modus möglich? Ich denke dabei auch an Anwendungen für verteilte soziale Netzwerke
Ich frage mich, ob LiveStore in Kombination mit React und WASM das von den meisten Musik-Apps genutzte Juce-Framework ersetzen könnte
Ich bin Beatmaker, und die Kombination aus Juce und C++ war für mich immer schwierig und einschüchternd. Ich würde gern wissen, ob LiveStore ein guter Einstieg für Leute sein könnte, die Musik-Apps entwickeln wollen
Ich habe den Vortrag auf der Local-first Conf gesehen, und derzeit erscheinen wirklich viele verschiedene Sync-Engines
LiveStore arbeitet sich tief in einen spannenden Bereich hinein, der Event Sourcing und Sync-Engine kombiniert
Ich war überrascht, dass das schon jetzt ein so robustes System ist
Ich habe es in den letzten Wochen selbst in einem neuen Projekt eingesetzt, und es läuft wirklich reibungslos
Glückwunsch zum Launch! Ich frage mich, ob dieses System zu der hier beschriebenen „1. Serialization”-Strategie passt
Wie bei ProseMirror-collab erwähnt, würde mich interessieren, ob es bei LiveStore ebenfalls zu dem Problem kommen kann, dass häufig aktualisierende Low-Latency-Clients die Updates von Clients mit hoher Latenz blockieren
LiveStore scheint wa-sqlite zu verwenden
Ich würde gern mehr über die Strategie zur Offline-Datenpersistenz hören, konkret ob OPFS (einschließlich Varianten wie AccessHandlePoolVFS) oder IndexedDB verwendet wird oder beides
Mich würde außerdem interessieren, wie ihr mit der browserübergreifenden Instabilität von OPFS und mit der 7-Tage-Aufbewahrungsrichtlinie von Safari IndexedDB umgeht
Und warum verwendet ihr wa-sqlite, obwohl SQLite offizielle WASM-Builds bereitstellt?
Ich habe LiveStore kürzlich im LocalFirst.fm-Podcast kurz vorgestellt (siehe Link: https://www.localfirst.fm/24)
Das wirkt wie ein sehr spannendes Projekt, aber ich bin auch etwas vorsichtig, nicht in eine Hype-Falle zu geraten
Ich experimentiere gerade mit dem Bau einer ähnlichen Local-First-App und Unterstützung für mehrere Geräte
Mich würde interessieren, ob sich auch Ende-zu-Ende-Verschlüsselung optional ergänzen ließe. Laut Dokumentation scheint es fast möglich zu sein, wenn man Verschlüsselung auf Ebene der Event-Payloads hinzufügt; einzig die Server-Log-Kompaktierung dürfte dadurch schwieriger werden
Ich entwickle LiveStore direkt aus einem Bedarf heraus, der bei meiner Arbeit an Overtone entstanden ist
Sowohl LiveStore als auch Overtone werden mit Blick auf langfristige Nachhaltigkeit entwickelt. Ende-zu-Ende-Verschlüsselung ist strukturell bereits möglich
Ich habe es selbst noch nicht ausprobiert, aber wenn es Probleme gibt, helfe ich gern weiter
Eine Möglichkeit wäre vermutlich auch, die Log-Kompaktierung nur clientseitig zu versuchen. Ich werde diesen Use Case bei der weiteren Entwicklung auf jeden Fall im Blick behalten
Ich bin skeptisch gegenüber dem Anspruch auf Cross-Platform-Support, wenn direkt am Anfang Android-Web-Unterstützung fehlt
Den Fortschritt kann man im offiziellen GitHub verfolgen: https://github.com/livestorejs/livestore/issues/321
Ich hoffe, es ist verständlich, dass der Bau eines derart ambitionierten Systems sehr viel Zeit und Aufwand erfordert, weil die Unterstützung der Web-APIs je nach Plattform unterschiedlich ausfällt
Eine interessante Kleinigkeit im Demo-Video! Bei 1:07 war der Ton stark nach links verschoben. Nichts Großes, aber vielleicht hilfreich als Hinweis
Beeindruckend, dass ihr auch Entwicklertools mitliefert; es wirkt, als hättet ihr das längere Zeit in einem eigenen Projekt getestet
Mich würde interessieren, wie ihr Compaction in langfristig laufenden Apps/Seiten handhaben wollt. Und Event Sourcing ist zwar ein starkes Konzept, aber je weiter sich die Anwendungsschicht entwickelt, desto schwieriger kann Code-Pflege werden (alte Clients, Schema-Migrationen usw.)
Overtone scheint mehrere Quellen zu unterstützen; wird es auch Offline-Wiedergabe geben? Gerade weil die Spotify-UI so unbequem ist, wäre eine Alternative sehr willkommen
Die Kernidee ist, jedem Event mehr semantische Informationen zu geben, sodass sich Überlappungen zwischen Events definieren lassen
In einer Todo-App könnte zum Beispiel ein „todoCompleted“-Event für dieselbe Aufgaben-ID die entsprechenden „todoCompleted“-/„todoUncompleted“-Events kompaktieren
Den Fortschritt kann man auf GitHub verfolgen: https://github.com/livestorejs/livestore/issues/254
Event Sourcing erfordert definitiv Disziplin und gutes Design. Bei Daten gibt es kein „free lunch“, entscheidend sind also die Trade-offs
Für meine Hauptanwendungsfälle wie Overtone fühlen sich die Trade-offs von Event Sourcing besser an
Für die Unterstützung älterer Versionen usw. gibt es mehrere einfache Ansätze; letztlich hängt es von den Eigenschaften und Trade-offs der jeweiligen Anwendung ab
Danke für das Interesse an Overtone. Auch ich habe das Projekt aus Unzufriedenheit mit Spotify begonnen. Bei der Offline-Wiedergabe hängt es von der Quelle der Musik ab
Eigene Alben etwa über Dropbox könnten unterstützt werden, bei Streaming-Diensten wie Spotify kann es hingegen von deren Richtlinien abhängen
Mir gefällt diese Architektur, besonders Event Sourcing
Allerdings muss man bei Event Sourcing aufpassen: Je nach gewünschter Sicht kann die Materialisierung (View Materialization) langsam sein, und mit wachsender Datenmenge wird das zunehmend problematisch
Die Lösung dafür besteht darin, Aktualisierungen der Materialisierung innerhalb von Transaktionen selbst zu verwalten, etwa über Trigger
Das muss man auch bei Replikation oder Sync berücksichtigen, und für die Konfliktauflösung sollte man sich unbedingt mit CRDT-Konzepten vertraut machen
Eine Art SQLite3-ähnliche Datenbank mit Postgres-Sprachfeatures wäre großartig, damit man Local-First und Remote-First einfach nur per Konfiguration umschalten könnte
Was den eigentlichen Punkt zu den Kosten der Materialisierung betrifft: Compaction wird künftig weiter verbessert, und das gesamte LiveStore-Framework ist mit viel Sorgfalt auf Performance-Optimierung ausgelegt