Local-first-Software ist zurück, und Sync-Engines erledigen die schwere Arbeit

Die meiste Software, die wir nutzen, behandelt den Server immer noch als einzige echte Kopie unserer Daten. Smartphone und Laptop sind nur dünne Fenster auf eine Datenbank irgendwo anders, und wenn die Verbindung abbricht, wird das Fenster leer. Die Local-first-Bewegung argumentiert, dass das verkehrt herum ist. Das Gerät sollte die Arbeitskopie halten, das Netzwerk sollte nur der Synchronisation dienen, und die App sollte weiterlaufen, wenn das Netz verschwindet.

Die Idee ist nicht neu, aber sie ist endlich praktikabel. Was sich geändert hat, ist kein philosophischer Wandel unter Entwicklern. Sync-Engines und konfliktfreie replizierte Datentypen (CRDTs) sind so ausgereift, dass sie den schwierigsten Teil lösen: zwei auf zwei Geräten gemachte Änderungen zusammenzuführen, ohne eine davon zu verlieren. Wer heute kollaborative Software baut, behandelt Synchronisation nicht mehr als Infrastrukturdetail, das man dem Backend-Team überlässt. Es ist eine Produktentscheidung mit Folgen für Datenmodell, Berechtigungen und Supportkosten.

Das Manifest von 2019 und warum es sieben Jahre dauerte

2019 veröffentlichte die Forschungsgruppe Ink & Switch einen Essay mit dem Titel Local-first software: you own your data, in spite of the cloud. Er nannte sieben Ideale: schnelle Reaktion ohne Ladeanzeigen, Arbeit, die einen Netzwerkausfall übersteht, Zusammenarbeit über Geräte und Personen hinweg, Daten, die das Unternehmen hinter der App überdauern, Sicherheit und Datenschutz als Standard, und Nutzer, die ihre eigenen Dateien kontrollieren. Kaum jemand widersprach der Liste. Das Problem waren die Implementierungskosten.

Eine Local-first-App zu bauen bedeutete früher, eigene Merge-Logik, eine eigene Speicherschicht und ein eigenes Replikationsprotokoll zu schreiben. Die meisten Teams wählten den reinen Cloud-Weg, weil er einfacher war, und Nutzer ertrugen die Ladeanzeigen. Diese Rechnung hat sich geändert, weil Bibliotheken wie Automerge und Yjs CRDTs in JavaScript nutzbar machten und Sync-Engines die Infrastruktur drumherum übernahmen.

Was eine Sync-Engine tatsächlich tut

Ein CRDT ist eine Datenstruktur, die so gebaut ist, dass sich Replikate in beliebiger Reihenfolge zusammenführen lassen und trotzdem zum gleichen Ergebnis konvergieren, ohne zentrale Schiedsinstanz. Texte, Listen und Maps lassen sich so modellieren. Eine Sync-Engine liegt darüber und übernimmt die unscheinbare Arbeit: Änderungen zwischen Client und Server bewegen, nur die Teilmenge der Daten replizieren, die jeder Nutzer sehen darf, den Zustand über Neustarts hinweg speichern und mit einer maßgeblichen Datenbank abgleichen.

Mehrere produktive Anwendungen laufen nach diesem Muster. Linear hat öffentlich über seinen clientseitigen Speicher geschrieben, der es dem Issue-Tracker erlaubt, sofort zu reagieren, während Änderungen im Hintergrund synchronisiert werden. Die Multiplayer-Bearbeitung in Figma ist ein weiterer bekannter Fall vieler Clients, die dasselbe Dokument gleichzeitig bearbeiten. Die Lehre aus diesen Produkten: Die lokale Kopie ist das, womit der Nutzer interagiert, und der Server wird zum Koordinator statt zum Engpass.

Wo das Modell bricht

CRDTs sind hervorragend darin, Textänderungen und Mengen von Elementen zu verschmelzen. Viel weniger hilfreich sind sie, wenn Ihre Geschäftsregeln auf globalen Invarianten beruhen. Buchen zwei Personen offline den letzten Platz in einem Flug, kann eine Merge-Funktion ohne Information, die nur der Server hat, nicht entscheiden, wer ihn bekommt. Dasselbe gilt für Zahlungen, Lagerbestände, die nicht negativ werden dürfen, und alles, was Geld oder rechtliche Verpflichtungen betrifft.

Schema-Migration ist das zweite Problem, das Teams unterschätzen. Wenn sich ein Client, der drei Monate hinterherhinkt, wieder verbindet, muss er Daten verstehen, die eine neuere Version geschrieben hat, und die neuere Version muss Daten einer alten Version verkraften. Das erfordert Versions-Gates im Client, sorgfältige Veralterung von Feldern und einen Plan für Clients, die nie aktualisiert werden. Speicher ist das dritte. Ein Smartphone hat begrenzten Platz und Akku, also braucht man Verdrängungsregeln, partielle Replikation und eine klare Antwort darauf, was passiert, wenn die lokale Datenbank die Kapazität des Geräts übersteigt.

Ein einfacher Entscheidungsrahmen

Bevor Sie sich für eine Local-first-Architektur entscheiden, stellen Sie drei Fragen zu jedem Datentyp in Ihrem Produkt. Erstens: Muss diese Art Daten offline funktionieren oder in unter etwa 100 Millisekunden reagieren? Zweitens: Bearbeiten mehrere Personen dasselbe Objekt gleichzeitig? Drittens: Würden die Daten dem Nutzer nutzlos, wenn er den Zugang zum Anbieter verliert?

Wenn alle drei mit Ja beantwortet werden, haben Sie einen starken Grund für Local-first, etwa bei Notizen, Aufgabenverwaltung und Design-Werkzeugen. Wenn die ersten beiden Antworten Nein lauten, ist ein konventionelles serverbasiertes Modell meist günstiger und leichter nachvollziehbar. Die meisten Produkte werden gemischt: Entwürfe und kollaborative Inhalte synchronisieren lokal, während Zahlungen, Rollen und Abrechnung serverseitig maßgeblich bleiben.

Praktische Erkenntnisse

• Klassifizieren Sie jede Entität Ihres Datenmodells als CRDT-zusammengeführt, serverseitig maßgeblich oder nur lesbar, und halten Sie das fest, bevor Sie Code schreiben.
• Versionieren Sie das Schema vom ersten Tag an und fügen Sie Versionsprüfungen im Client hinzu, damit alte Clients kontrolliert scheitern statt Daten zu beschädigen.
• Testen Sie auf günstigen Android-Geräten mit wenig Speicher, nicht nur auf dem neuesten iPhone.
• Führen Sie intern einen einwöchigen Offline-Test durch. Nutzen Sie den Flugmodus für normale Arbeit und notieren Sie jede Stelle, an der die App Sie blockiert. Das sind Ihre echten Anforderungen.

Local-first ersetzt die Cloud nicht. Es ist eine Neuverteilung: Das Gerät übernimmt mehr von der Arbeit, die dem Nutzer wichtig ist, und der Server die Koordination, in der er gut ist. Teams, die das richtig umsetzen, liefern Apps, die sich schneller anfühlen und schlechte Netze überstehen. Teams, die Synchronisation als Nachgedanken behandeln, werden weiterhin Ladeanzeigen zeigen.