Was ist Offline-First-Datensynchronisierung?

Offline-First-Synchronisierung ist eine Architektur, in der die App zuerst lokal liest und schreibt und sich dann online mit dem Server abgleicht. Das Netz hört auf, eine Abhängigkeit zu sein, und wird zum Hintergrundprozess – jeder Bildschirm rendert aus dem Gerät, jeder Tipp schreibt auf das Gerät, und eine Sync-Schicht begleicht die Rechnung mit dem Backend, sobald die Verbindung es erlaubt. Das Schwierige war nie, Daten lokal zu speichern; es ist das, was passiert, wenn zwei Kopien der Wahrheit uneins sind.

Das Wichtigste in Kürze

Anheften, lesen, einreihen: die Offline-Schleife in Code

Die Variante des Musters im mobilen SDK – heften Sie an, was die Bildschirme brauchen, und reihen Sie ein, was die Nutzer ändern:

// JavaScript — Back4app JS SDK with the Local Datastore enabled
Parse.enableLocalDatastore();

// Read: serve the screen from the local store — instant, works offline
const query = new Parse.Query('Task');
query.fromLocalDatastore();
render(await query.find());

// Write: durable locally now, queued for the server automatically
const task = new Parse.Object('Task');
task.set('title', 'Inspect site 14');
task.set('done', false);
await task.pin();          // survives restarts, feeds local reads
task.saveEventually();     // replays when the network returns

// Flutter / Dart — Back4app Flutter SDK with local storage enabled
// Parse().initialize(..., coreStore: await CoreStoreSembastImp.getInstance())

// Read: serve the screen from pinned data — instant, works offline
final pinned = await ParseObject('Task').fromPin('openTasks');
render(pinned);

// Write: durable locally now, synced when the network allows
final task = ParseObject('Task')
  ..set('title', 'Inspect site 14')
  ..set('done', false);
await task.pin();                 // survives restarts, feeds local reads

final response = await task.save();
if (!response.success) retryLater(task);   // replay from the outbox

// iOS / Swift — Back4app iOS SDK with the Local Datastore enabled
// (in the app delegate) Parse.enableLocalDatastore()

// Read: serve the screen from the local store — instant, works offline
let query = PFQuery(className: "Task")
query.fromLocalDatastore()
query.findObjectsInBackground { tasks, _ in
  render(tasks)
}

// Write: durable locally now, queued for the server automatically
let task = PFObject(className: "Task")
task["title"] = "Inspect site 14"
task["done"] = false
task.pinInBackground()     // survives restarts, feeds local reads
task.saveEventually()      // replays when the network returns

// Android / Kotlin — Back4app Android SDK with the Local Datastore enabled
// (before Parse.initialize) Parse.enableLocalDatastore(context)

// Read: serve the screen from the local store — instant, works offline
val query = ParseQuery.getQuery<ParseObject>("Task")
query.fromLocalDatastore()
query.findInBackground { tasks, _ ->
    render(tasks)
}

// Write: durable locally now, queued for the server automatically
val task = ParseObject("Task")
task.put("title", "Inspect site 14")
task.put("done", false)
task.pinInBackground()     // survives restarts, feeds local reads
task.saveEventually()      // replays when the network returns

Zwei Aufrufe tragen die gesamte Architektur. Pin macht Objekte auf dem Gerät dauerhaft und abfragbar – dieselbe Abfrageschnittstelle wie auf dem Server, nur auf den lokalen Speicher gerichtet (Local Datastore in den SDKs oben). Save-Eventually nimmt den Schreibvorgang jetzt an und übernimmt seine Zustellung später. Alles Weitere in diesem Artikel beschreibt, was zwischen diesen beiden Aufrufen geschieht.

Puffer oder Quelle der Wahrheit? Die Entscheidung unter der Entscheidung

Jeder Offline-First-Entwurf wählt stillschweigend eine von zwei Haltungen für den lokalen Speicher, und der meiste Sync-Schmerz entsteht daraus, dass diese Wahl nicht bewusst getroffen wurde.

Lokaler Speicher als Puffer. Der Server bleibt maßgeblich; das Gerät hält eine Arbeitskopie plus eine Outbox mit Absichten. Konflikte werden zugunsten des Servers oder nach einer einfachen Regel aufgelöst, und ein Gerät lässt sich jederzeit durch erneutes Laden reparieren. Das ist der richtige Standard für betriebliche Apps – CRM-Checklisten, Inspektionen im Außendienst, Auftragserfassung –, weil das Nachdenken einfach bleibt: Die Wahrheit lebt an einem Ort, die Geräte hinken ihr nur hinterher.

Lokaler Speicher als Replikat. Die Wahrheit wird zwischen Peers ausgehandelt, und der Server ist nur ein Replikat unter mehreren – die Haltung kollaborativer Editoren und Notiz-Apps, die versprechen, alles zusammenzuführen. Das erkauft Widerstandsfähigkeit und Nutzervertrauen zum Preis echter Distributed-Systems-Maschinerie: Version Vectors, um Nebenläufigkeit zu erkennen, Merge-Funktionen pro Datentyp und Eventual Consistency (letztendliche Konsistenz) als stärkste Garantie, die Sie guten Gewissens zusagen können.

Die Haltung wird pro Datensatzbestand gewählt, nicht pro App: Dieselbe Außendienst-App kann die Arbeitsaufträge des Technikers als Replikat behandeln (sie müssen den ganzen Tag im Keller bearbeitbar bleiben) und den Teilekatalog als Read-Through-Puffer.

Die Sync-Schleife von Anfang bis Ende

Die Schleife hat eine ausgehende und eine eingehende Hälfte, und sie treffen sich bei der Conflict Resolution.

Ausgehend: Schreibvorgänge in der Warteschlange und Wiedergabe. Offline-Schreibvorgänge werden lokal bestätigt und an eine dauerhafte Outbox angehängt – die Oberfläche spiegelt die Absicht sofort, ehrlich als “ausstehend” gekennzeichnet, wo es darauf ankommt. Bei der Wiederverbindung wird die Queue der Reihe nach wiedergegeben. Die Ingenieursarbeit steckt in den Fehlerfällen: Vorübergehende Fehler werden mit Backoff wiederholt; Berechtigungs- und Validierungsablehnungen müssen dem Nutzer sichtbar werden und dürfen nicht endlos wiederholt werden; und Operationen sollten idempotent sein, denn eine verlorene Bestätigung bedeutet, dass dieselbe Operation zweimal ankommen kann. “Status auf erledigt setzen” zweimal wiederzugeben ist harmlos; “Bestand um 3 erhöhen” zweimal wiederzugeben ist ein Bug.

Eingehend: Delta-Abruf. Bei der Wiederverbindung alles neu zu laden verschwendet Bandbreite und Akku; produktionsreife Synchronisierung holt Änderungen seit einem Prüfpunkt – eine Updated-at-Marke in einfachen Entwürfen, eine serverseitige Sequenznummer oder ein Change Feed in robusteren. Dieselben Ereignisse, die im Online-Betrieb Live Queries antreiben, dienen auch als eingehender Delta-Strom, und genau deshalb sind Offline-Sync und Echtzeit-Sync ein Kontinuum und nicht zwei Features.

Last-Write-Wins vs. Merge vs. CRDTs

Zwei ehrliche Anmerkungen zu dieser Tabelle. Erstens sind Zeitstempel wackliger, als sie aussehen – Geräteuhren driften, weshalb ernsthaftes Last-Write-Wins die serverseitige Eingangszeit oder logische Versionen nutzt (Version Vectors, wenn nebenläufige Bearbeitungen erkannt statt geraten werden müssen). Zweitens liegt der praktische Idealpunkt für mobile Apps bei CRDT-lite: Vollständige CRDT-Bibliotheken sind schweres Gerät, aber die Idee pro Feld zu übernehmen kostet fast nichts – modellieren Sie eine Stückzahl als Inkrement-Operationen statt als gespeicherte Summe und Tags als Add/Remove-Mengen statt als Array, und diese Felder hören schlicht auf, in Konflikt zu geraten. Die Strategie wird pro Feld gewählt; Apps, die eine einzige globale Regel festlegen, haben sie meist für irgendein Feld falsch gewählt.

Typische Anwendungsfälle

• Außendienst – Inspektionen, Zustellungen, Arbeiten an Versorgungsnetzen: Die Baustelle ist genau der Ort, an dem die Netzabdeckung stirbt, also muss die Erfassung lokal und die Synchronisierung opportunistisch sein.
• Notizen und persönliche Produktivität – ein Nutzer, mehrere Geräte: Konflikte sind selten und meist selbst verschuldet, was Merge-Regeln beherrschbar macht.
• Kassen- und Kiosk-Apps – die Schlange muss auch durch einen Router-Neustart weiterlaufen; Transaktionen werden wiedergegeben, sobald die Leitung zurück ist.
• Reise-Apps – Reisepläne, Karten und Tickets werden genau dort genutzt, wo die Verbindung am schlechtesten ist: in Flugzeugen, Zügen, im Roaming.
• Produkte für Schwellenmärkte und geringe Bandbreite – unterbrochene, volumenabhängig abgerechnete Verbindungen machen Delta-Sync im Hintergrund zum einzig respektvollen Entwurf, unabhängig vom Plattform-Mix.

Sollten Sie Offline-First bauen? Eine Entscheidungsmatrix

Der Mittelweg ist legitim und verbreitet: Lesezugriffe für sofortige Bildschirme cachen, Offline-Schreibvorgänge nur für die wenigen Datenbestände erlauben, die sie wirklich brauchen, und den Rest Online-First hinter ehrlichen Verbindungsanzeigen halten.

Grenzen und Trade-offs

• Conflict Resolution ist eine Produktentscheidung im Ingenieursgewand. “Welche Bearbeitung überlebt?” hat keine technisch richtige Antwort – jemand muss die Regel pro Feld verantworten, und “stillschweigend die neueste behalten” ist eine Wahl mit einem Opfer.
• Die Outbox ist eine Warteschlange von Verbindlichkeiten. Veraltete ausstehende Schreibvorgänge eines Geräts, das nach zwei Wochen wieder auftaucht, können in eine veränderte Welt hinein wiedergegeben werden; Ablaufregeln und Validierung bei der Wiedergabe sind Pflicht, nicht Paranoia.
• Sync-Bugs sind die schlimmste Fehlerklasse, die Sie sich einhandeln können. Sie treten nur bei bestimmten Verschränkungen von Bearbeitungen und Verbindungszuständen auf – investieren Sie in deterministische Wiedergabetests und eine sichtbare Anzeige des Sync-Status, sonst debuggen Sie für immer per Anekdote.
• Lokale Wahrheit altert. Bildschirme müssen dort ehrlich über Veralterung sein, wo es zählt (Preise, Verfügbarkeit) – “Stand vor 2 Stunden” ist ein Feature, keine Entschuldigung.
• Speicher und Identität bremsen. Gerätespeicher brauchen Migrationen wie jede Datenbank, und offline angelegte Datensätze brauchen clientseitig erzeugte Identitäten, die die Reise zum Server überstehen, ohne sich zu verdoppeln.

Offline-First-Synchronisierung mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die mobilen SDKs liefern die Puffer-Haltung schlüsselfertig: Der Local Datastore heftet die Ergebnisse jeder Abfrage für Offline-Lesezugriffe über dieselbe Abfrage-API an, saveEventually gibt jedem Schreibvorgang eine dauerhafte Outbox mit geordneter Wiedergabe, und beforeSave-Trigger in Cloud Code sind der natürliche Ort für serverseitige Konfliktregeln – Versionsprüfungen, Merge-Regeln, Validierung bei der Wiedergabe –, durchgesetzt auf jedem Schreibpfad. Ergänzen Sie den Live-Query-Strom für eingehende Deltas, solange die App online ist, und die Sync-Schleife aus dem Diagramm oben ist Konfiguration plus Regelwerk, kein Subsystem, das Sie bauen müssen.