Das Entwerfen von Offline-zuerst-orientierten Frontends als Repliken: Warteschlangen, Wiederholungsversuche, Konflikte

Ein Frontend, das bei einer schnellen, stabilen Verbindung gut funktioniert, sagt nur wenig aus. Die interessanten Fälle treten auf, wenn eine Anfrage hängen bleibt, das WLAN ausfällt, ein Zug in einen Tunnel einfährt, ein Laptop zwischen Netzwerken wechselt oder das Telefon den Empfang verliert, kurz nachdem jemand auf Speichern geklickt hat. Die herkömmliche Frontend-Architektur betrachtet all diese Fälle als Ausnahmen: API aufrufen, warten, den Zustand aktualisieren und fortfahren.

Ein offline-first-Design geht von dem entgegengesetzten Prinzip aus: Das Netzwerk darf versagen, und die Anwendung muss dennoch nützlich bleiben. Das klingt nach einer Verbesserung der Benutzererfahrung, handelt sich aber um eine strukturelle Veränderung. Sobald der Browser Daten lesen, Änderungen annehmen, sie speichern und später synchronisieren kann, ist er kein „dünner Client“ mehr, sondern ein Knoten in einem verteilten System. Diese Anleitung erläutert, was das in der Praxis bedeutet: Wo Daten gespeichert werden sollten, wie Schreibvorgänge sicher in der Warteschlange abgelegt und wiederholt werden, wie die Benutzeroberfläche den Synchronisierungsstatus mitteilen sollte – und warum die Konfliktbehandlung letztendlich eine Produktentscheidung ist.

Das Netzwerk aus dem kritischen Pfad entfernen

Stellen Sie sich eine einfache Notiz-App vor. Jemand öffnet eine Notiz, ändert den Titel und speichert sie. Bei einem traditionellen Design sieht der Ablauf so aus:

User → React → Server
              ↓
            Data

Der Server befindet sich direkt im Interaktionsablauf. Ein langsamer Server bedeutet eine langsame Benutzeroberfläche; ein unterbrochener Verbindungsaufbau führt zum Stillstand der Speicherung; eine fehlgeschlagene Anfrage zwingt die App, sofort zu entscheiden, was mit den Änderungen des Benutzers geschehen soll.

Durch ein Offline-First-Design wird ein erheblicher Teil dieser Verantwortung auf den Browser übertragen:

User → React → Local Store
                    ↓
                Sync Later

Der Server wird dadurch nicht unwichtig. In den meisten Systemen bleibt er weiterhin der Ort, an dem die gemeinsamen Daten gespeichert sind. Was sich ändert, ist, dass er nicht mehr für jede einzelne Interaktion erreichbar sein muss. Diese Trennung zwischen der Bestätigung der Aktion des Benutzers und deren Übermittlung an den Backend-Server bildet die Grundlage für alles Weitere.

Der Browser speichert nun wichtige Zustände

Falls die App auch ohne Internetverbindung weiterarbeiten muss, benötigt sie eine zuverlässige Speicherlösung auf dem Gerät. Für etwas mehr als nur kleine Einstellungen bedeutet das in der Regel IndexedDB oder eine darüber liegende, fortgeschrittene Datenbank. Die konkrete Bibliothek ist weniger wichtig als die Folge: Der Browser besitzt nun einen Zustand, den man sich nicht leisten kann zu verlieren.

Dazu gehören gespeicherte Einträge und ungesendete Entwürfe, Änderungen, die noch übertragen werden müssen, Synchronisierungsmetadaten wie Zeitstempel und Versionen sowie Aufzeichnungen darüber, was bereits hochgeladen wurde. Damit stellt sich eine Frage, die eine einfache Anfrage-Antwort-Anwendung niemals beantworten muss: Was geschieht, wenn die Kopie im Browser und die auf dem Server nicht übereinstimmen? In einer Offline-first-Anwendung ist das kein Sonderfall – es gehört zur Normalität.

Caching von Lesevorgängen bedeutet nicht automatisch Offline-First

Diese Unterscheidung lässt sich leicht verwischen. Eine App kann API-Antworten im Cache speichern und dennoch vollständig vom Netzwerk abhängig sein. Angenommen, sie lädt eine Liste von Projekten herunter und speichert das Ergebnis lokal, sodass die Liste auch ohne Verbindung wieder angezeigt wird. Das ist nützlich, deckt aber nur Lesevorgänge ab.

Das Design ist erst dann wirklich offline-first, wenn Benutzer Daten auch ohne Verbindung ändern können: ein Projekt erstellen, einen Dokument bearbeiten, eine Aufgabe abhaken oder eine Einstellung anpassen. Solche Aktionen können nicht einfach verschwinden, nur weil keine HTTP-Anfrage gesendet wurde. Die App benötigt einen Ort, um festzuhalten, was der Benutzer tun wollte, damit die Absicht erhalten bleibt, bis sie ausgeliefert werden kann.

Jeder Offline-Schreibvorgang wird zu einer Synchronisierungsverpflichtung

Wenn jemand ein Dokument offline bearbeitet, besteht der übliche Ansatz darin, die Änderung zunächst im lokalen Speicher anzuwenden und anschließend die noch auszuführende Operation zu protokollieren, die schließlich zum Server gesendet werden muss. In vereinfachter Form:

User Saves
    ↓
Save Locally
    ↓
Update UI
    ↓
Add To Queue
    ↓
Sync When Online

Achten Sie auf die Reihenfolge: Der lokale Schreibvorgang sowie die Aktualisierung der Benutzeroberfläche finden vor dem Einplanen in die Warteschlange statt, weshalb die Benutzeroberfläche sofort reagieren kann. Der Abschnitt in der Warteschlange verdient mehr Aufmerksamkeit, als er normalerweise erhält. Es handelt sich dabei nicht um einen Haufen fehlerhafter Anfragen, sondern um ein zuverlässiges Protokoll der Arbeiten, deren Abschluss der Benutzer vom System erwartet.

Dafür gelten konkrete Anforderungen. Die Warteschlange muss bei Neu laden von Seiten, Neustarts des Browsers, vorübergehenden Serverfehlern sowie Netzwerkänderungen erhalten bleiben, was bedeutet, dass sie in einer persistenten Speicherung statt in einem JavaScript-Array untergebracht werden sollte. Zudem muss sie sich korrekt verhalten, wenn eine Operation zweimal oder öfter übermittelt wird. Diese zweite Anforderung führt zu einem der schwierigsten Fehlermöglichkeiten in der gesamten Konstruktion.

Wenn Erfolg genauso aussieht wie Fehler

Betrachten Sie diese Abfolge: Der Benutzer speichert die Daten. Die Anfrage erreicht den Server. Der Server schreibt die Daten erfolgreich ab. Bevor jedoch die Antwort zurückkehren kann, bricht die Verbindung ab. Der Client geht davon aus, dass der Speichervorgang fehlgeschlagen ist; der Server hingegen weiß, dass er erfolgreich war.

Client
  |
  | Save
  v
Server
  |
  | Saved
  X
Response Lost
  |
  v
Client Retries

Falls der Client einfach erneut versucht, kann der Server dieselbe Änderung zweimal anwenden. Bei einer idempotenten „set title“-Operation mag das harmlos sein, doch bei „add item“, „create order“ oder „increment counter“ entstehen Duplikate.

Deshalb ist die Idempotenz in offline-first-Systemen von zentraler Bedeutung. Jede Mutation benötigt eine stabile Identität, damit der Server erkennen kann, dass ein erneuter Versuch derselbe logische Vorgang ist und nicht einer Neuen. Ein gängiger Ansatz besteht darin, beim ersten Erfassen der Änderung auf dem Client eine Operation-ID zu generieren, sie zusammen mit der in der Warteschlange befindlichen Mutation zu speichern und bei jedem Versuch mitzusenden. Der Server verfolgt, welche IDs er bereits verarbeitet hat, und bestätigt bei Wiederholungen diese, ohne sie erneut anzuwenden.

Es handelt sich dabei nicht um eine Leistungsanpassung. Es ist vielmehr das Mittel, das verhindert, dass ein unzuverlässiges Netzwerk gewöhnliche Wiederholungsversuche in doppelte Arbeit umwandelt. Ein praktischer Aspekt, der richtig umgesetzt werden muss: Die ID muss einmal erstellt und zusammen mit dem Warteschlangeneintrag gespeichert werden, nicht bei jedem Anfrage erneut generiert werden – andernfalls erscheint jeder Wiederholungsversuch wieder als neu.

Optimistische Benutzeroberfläche als Ausdruck der Absicht

Optimistische Aktualisierungen werden in der Regel als Möglichkeit dargestellt, Apps schneller erscheinen zu lassen. In Apps, die vorrangig offline funktionieren, haben sie noch größeres Gewicht. Wenn ein Benutzer eine Aufgabe offline abschließt und die Benutzeroberfläche auf eine Serverantwort wartet, bevor sie diese anzeigt, wirkt die App einfach defekt. Die lokale Änderung sollte normalerweise sofort sichtbar sein, und die Synchronisierung kann später die entfernte Seite auf den neuesten Stand bringen.

Dies führt zu einer nützlichen Aufteilung der Verantwortlichkeiten:

• Der lokale Zustand spiegelt wider, was der Benutzer getan hat.

Der Synchronisierungsstatus zeigt an, ob das gemeinsam genutzte System aufgeholt hat.

Beide Aspekte hängen zusammen, sind aber nicht identisch; ihre getrennte Darstellung ermöglicht es der Benutzeroberfläche, ehrlicher zu kommunizieren als ein einziger Online/Offline-Indikator. Beispielsweise kann ein Element wie folgt markiert werden:

• auf diesem Gerät gespeichert
• für die Synchronisierung in der Warteschlange
• wird gerade synchronisiert
• synchronisiert
• braucht die Aufmerksamkeit des Benutzers

Ein Benutzer, der „für die Synchronisierung in der Warteschlange“ sieht, versteht, dass die Daten sicher sind, aber noch nicht geteilt wurden – was weitaus beruhigender ist als ein unklarer Ladebalken oder eine Fehlermeldung.

Lassen Sie den lokalen Speicher die Daten verwalten und React sie darstellen

Eine häufige Quelle für unbeabsichtigte Komplexität sieht so aus: Die Daten werden in IndexedDB gespeichert, in den React-State geladen, erneut in einen separaten Client-Seiten-Speicher kopiert und anschließend wird alles manuell synchron gehalten. Die Anwendung enthält nun mehrere Darstellungen derselben Datensätze, was zu veralteten Werten, Rennbedingungen, unnötigen Neuladungen sowie Synchronisierungsfehlern führt, die ausschließlich im Frontend auftreten.

Ein saubereres Modell überträgt die Verwaltung der persistenten Daten auf den langlebigen lokalen Speicher, wobei React lediglich als Ansicht darüber fungiert:

Local Store
     ↓
  React UI
     ↓
   User
     ↓
Local Store

Der Schleifenmechanismus ist entscheidend: Die Benutzeroberfläche liest aus dem lokalen Speicher, der Benutzer handelt, und die Aktion schreibt wieder in den lokalen Speicher, der anschließend die Benutzeroberfläche erneut steuert. React übernimmt weiterhin die Verarbeitung von Interaktionen und der Darstellung; die Datenbank ist für den auf dem Client gespeicherten Zustand verantwortlich, der erhalten bleiben muss. In der Praxis bedeutet dies in der Regel, dass Komponenten sich an Abfragen gegen den lokalen Speicher abonnieren, anstatt die Ergebnisse in den Zustand der Komponenten zu kopieren. Der Vorteil wächst mit der Größe der Anwendung, denn es gibt genau einen Ort, an dem man nachschauen kann, wenn ein Wert falsch erscheint.

Wenn beide Geräte richtig liegen

Der Konfliktlösung kommt der Punkt, an dem das Offline-First-Konzept nicht mehr eine Speicherfrage darstellt, sondern zu einer Frage der verteilten Systeme wird. Angenommen, jemand öffnet dasselbe Dokument auf einem Laptop und einem Handy, und beide gehen offline. Auf dem Laptop wird der Titel in Frontend Architecture geändert; auf dem Handy in Offline Architecture. Jedes Gerät hat eine gültige Änderung vorgenommen, ohne vom anderen zu wissen. Wenn beide wieder verbunden sind, kommt es zum Konflikt:

Laptop              Phone
   |                   |
   v                   v
"Frontend App"     "Offline App"
   |                   |
   +--------+----------+
            |
            v
         Conflict

Es gibt keine universell richtige Lösung. Soll die neueste Änderung gewinnen? Soll die Serverversion Vorrang haben? Können die Felder zusammengeführt werden? Soll der Benutzer entscheiden? Sollen unterschiedliche Felder unterschiedlichen Richtlinien folgen?

Die zentrale Erkenntnis ist, dass die Konfliktlösung eine Produktentscheidung ist, die wie eine technische Entscheidung aussieht. Das Prinzip „Letzter Schreiber gewinnt“ kann beispielsweise bei Benutzeroberflächen-Einstellungen völlig akzeptabel sein. Bei gemeinsam bearbeiteten Dokumenten, Finanzdaten, Lagerbeständen oder wichtigen Geschäftsunterlagen kann es jedoch inakzeptabel sein, da das stillschweigende Ignorieren einer Seite echte Arbeit verloren gehen lässt oder falsche Gesamtwerte erzeugt. Die Architektur muss festlegen, was „richtig“ für jede Datensorte bedeutet – deshalb müssen Produktverantwortliche an dieser Diskussion teilnehmen, anstatt es denen zu überlassen, die den Synchronisierungscode schreiben. Beachten Sie außerdem, dass auch der Begriff „neueste“ problematisch ist: Die Uhrzeiten der Geräte verschieben sich, wodurch Richtlinien, die auf Client-Uhrzeiten basieren, den falschen Gewinner auswählen können – es sei denn, die Reihenfolge ergibt sich aus etwas Zuverlässigerem wie serverseitig zugewiesenen Versionen.

Fernänderungen benötigen denselben Eingangspunkt

Offline-first bedeutet nicht, dass die Synchronisierung nur beim Öffnen der App stattfindet. Andere Benutzer und Geräte ändern dieselben Daten, und der Server erhält weiterhin Änderungen von anderen Quellen. Ein Echtzeitkanal fügt daher eine zweite Fließrichtung hinzu:

Local Changes
      ↓
     Sync
      ↓
    Server
      ↓
  New Changes
      ↓
 Local Store
      ↓
      UI

Dies führt zu einer wichtigen Regel: Änderungen, die vom Server kommen, sollten im selben lokalen Datenmodell landen, das die Benutzeroberfläche bereits liest. Wenn lokale Änderungen einen Weg nehmen und entfernte Aktualisierungen einen anderen, müssen React-Komponenten mit komplizierter Logik arbeiten, um die beiden in Einklang zu bringen. Wenn der lokale Speicher der einzige Treffpunkt ist, bleibt die Darstellung einfach: Die Benutzeroberfläche kümmert sich nicht darum, ob eine Änderung auf diesem Gerät oder auf einem anderen entstanden ist.

Man geht davon aus, dass der Browser selbst versagen kann

Es gibt noch einen weiteren Fehlermodus, der leicht übersehen werden kann: Der Browser könnte vor dem Wiederherstellen der Verbindung verschwinden. Die Registerkarte wird geschlossen, der Browser stürzt ab, das Betriebssystem beendet den Prozess, die Akku des Laptops ist leer oder der Prozess verschwindet mitten in einer Synchronisierung. Jede Arbeit, die nur im Speicher vorhanden ist, geht dabei verloren.

Deshalb muss der Synchronisierungsstatus dauerhaft gespeichert werden. Eine ernstzunehmende App, die vorrangig offline funktioniert, sollte den Browser als unzuverlässigen Knoten betrachten, und ihre lokale Datenbank muss genügend Informationen enthalten, um die ausstehenden Aufgaben beim Neustart der App wiederherzustellen: welche Operationen sind ausstehend, welche waren im Gange und wie der letzte bekannte Serverzustand war. Ein nützlicher Test besteht darin, während der Entwicklung die Registerkarte mitten in einer Synchronisierung zu beenden und sicherzustellen, dass beim nächsten Start nichts verloren geht oder dupliziert wird.

Service Workers sind nur ein Bestandteil, nicht die gesamte Architektur

Service Workers sind von großem Wert, insbesondere zur Caching von Anwendungsressourcen und zum Abfangen von Netzwerkanfragen; falls Sie eine Auffrischung der Funktionsweise benötigen, lesen Sie die Anleitung zur Aktivierung der Offline-Unterstützung mit Service Workers. Doch die Registrierung eines Service Workers macht eine App noch nicht automatisch offline-first:

• Ein registrierter Service Worker verhindert nicht, dass ungespeicherte Änderungen des Benutzers verloren gehen.
• Cachede Bündel ermöglichen es der App, offline zu starten, sagen aber nichts darüber aus, wohin Offline-Einträge gespeichert werden.
• Das Bereitstellen veralteter API-Antworten aus dem Cache stellt keine Konfliktlösung dar.

Offline-first ist eine Eigenschaft der Architektur, kein Browser-Feature, das man aktivieren kann. Was es tatsächlich funktionieren lässt, ist eine lokale Datenschicht, dauerhafte Änderungen, ein Synchronisierungsprozess, explizite Fehlerbehandlung, eine Richtlinie für Konflikte sowie eine Benutzeroberfläche, die akzeptiert, dass die Fernsynchronisierung Zeit in Anspruch nehmen kann.

Die Komplexität verschiebt sich; sie verschwindet nicht

Die unangenehme Realität ist, dass Software im Offline-first-Modus nicht einfacher ist. Die Komplexität wird lediglich an einen anderen Ort verlagert. Eine herkömmliche Anwendung kann mit dem Senden einer Anfrage und dem Warten auf die Antwort auskommen. Eine Offline-first-Anwendung muss sich mit einer Reihe schwierigerer Fragen auseinandersetzen:

• Was passiert, wenn der Server nicht erreichbar ist?
• Was passiert, wenn der Browser vor Abschluss der Synchronisierung geschlossen wird?
• Was passiert, wenn die Anfrage ankommt, aber keine Antwort?
• Was passiert, wenn derselbe Datensatz auf einem anderen Gerät geändert wird?
• Was passiert, wenn beide Änderungen gültig sind?

Welches Ergebnis gilt für dieses Produkt als richtig?

Das sind klassische Probleme von verteilten Systemen, und die Tatsache, dass ein Browser einer der Teilnehmer ist, macht sie nicht einfacher. Bevor man sich für einen offline-first-Ansatz entscheidet, lohnt es sich, zu prüfen, ob das Produkt tatsächlich Schreibvorgänge im Offline-Modus benötigt. Für ein Dashboard, das die Nutzer nur lesen, können gecachte Lesevorgänge zusammen mit einer klaren Offline-Meldung den größten Nutzen zu einem Bruchteil der Kosten liefern.

Lokale Daten erfordern ein auf Servern angewandtes Sicherheitskonzept

Daten, die auf einem Gerät gespeichert sind, bleiben weiterhin Daten mit all den damit verbundenen Verantwortlichkeiten. Wenn sensible Informationen im Browser gespeichert sind, muss man bedenken, was passiert, wenn das Gerät kompromittiert wird, wenn mehrere Personen es teilen oder wenn ein Konto ausgeloggt wird und eine andere Person das Gerät übernimmt. Die lokale Speicherung sollte denselben Sicherheitsgrundsätzen wie die Backend-Speicherung folgen:

• Speichern Sie nur das, was der Client wirklich benötigt.
• Definieren Sie Ablaufregeln sowie das Vorgehen beim Abmelden.
• Betrachten Sie den Browser-Speicher nicht als sicheren Tresor.
• Entscheiden Sie bewusst, welche Datensätze überhaupt auf dem Gerät gespeichert werden dürfen.

Ein Offline-First-Ansatz verbessert die Verfügbarkeit, doch dieser Vorteil darf niemals darin bestehen, Informationen preiszugeben, die ursprünglich gar nicht lokal gespeichert werden sollten.

Design unter Berücksichtigung von Fehlern statt des idealen Szenarios

Eine auffällige Eigenschaft von Ansätzen im Offline-First-Modell ist, dass die Architektur klarer wird, sobald man aufhört, für das ideale Szenario zu designen. Die Fragen ändern sich:

• Anstelle von „Wie hole ich diese Daten?“ fragen Sie, wo die Daten liegen sollen, wenn das Netzwerk nicht verfügbar ist.
• Anstelle von „Wie versuche ich den Antrag erneut?“ fragen Sie, wie der Client erkennen kann, ob der Server den Antrag bereits bearbeitet hat.

Anstatt sich zu fragen, wie man Daten in den React-State einfügt, sollte man prüfen, welcher Teil des Systems tatsächlich die Daten besitzt.

Anstatt kollidierende Anfragen als Fehler zu betrachten, den man beheben muss, sollte man fragen, was Korrektheit für dieses Produkt bedeutet.

Durch konsequentes Beantworten der zweiten Version jeder Frage entsteht ein stabileres Design.

Ziel ist eine Benutzererfahrung, die die Nutzer kaum bemerken

Nutzer haben kein Interesse an Synchronisierungsmechanismen, Datenbanktransaktionen, Wartezeitstrategien, Verschmelzungsalgorithmen oder Replikation. Sie möchten weiterarbeiten können. Sie erwarten, dass ein Entwurf nach einem Verbindungsabbruch weiterhin vorhanden ist, dass eine Aufgabe im Zug abgeschlossen bleibt und dass eine App nicht sofort nutzlos wird, sobald sich das WLAN-Symbol ändert. Die dahinterliegenden Mechanismen können komplex sein; die Benutzererfahrung sollte es nicht sein.

Wichtige Erkenntnisse

Die zentrale Idee, die das Design zusammenhält, lautet folgendermaßen: ein offline-first-Frontend ist ein verteiltes System, in dem der Browser eine zweite Kopie der Daten hostet. Aus dieser Perspektive erhalten die einzelnen Komponenten klarere Rollen:

• IndexedDB ist nicht nur eine Browser-Speicherlösung; es gehört zur Datenschicht der Anwendung.
• Die Mutation-Queue dient nicht nur zum Wiederholen von Vorgängen; sie ist eine zuverlässige Aufzeichnung der Benutzerabsichten, wobei jeder Eintrag eine stabile ID für idempotente Wiederholungen benötigt.
• Eine optimistische Benutzeroberfläche ist kein Geschwindigkeitstrick; sie sorgt dafür, dass das Produkt weiterhin nutzbar bleibt, solange der Backend-Prozess Zeit benötigt, abzuschließen.
• Konfliktbehandlung ist kein Randfall; sie ist Teil der Definition der Korrektheit des Produkts.
• Synchronisierung ist nichts, was am Ende hinzugefügt werden muss; sie ist bereits Teil der Architektur.

Netzwerke versagen, Server reagieren träge, Geräte sind kurzzeitig unkoordiniert und Browser verschwinden ohne Vorwarnung. Ein gut konzipierter Offline-First-Frontend sorgt dafür, dass die Arbeit des Benutzers all dem standhält und sein Versprechen einhält, selbst wenn eine Verbindung nicht möglich ist.