Die meisten Anwendungen behandeln die fehlende Verbindung als Unfall. Sie öffnen einen Bildschirm, das Netzwerk verschwindet und die entmutigende Warnung erscheint: Kein Internet, versuchen Sie es erneut. Die App gibt auf und der Benutzer auch.
Offline-first kehrt diese Logik von Grund auf um. Die Voraussetzung ist, dass das Fehlen einer Verbindung der Normalzustand und ihr Vorhandensein der Bonus ist. Es ist kein Pessimismus, es ist Realismus. Jeder, der hybride Feld-, Mobil- oder Web-Apps erstellt, weiß, dass das Netzwerk mehr versagt, als wir zugeben möchten.
Offline als Regel und nicht als Fehler behandeln
Der Unterschied beginnt im Kopf des Designers. Im gängigen Modell besteht der glückliche Weg darin, online zu sein, und offline ist eine schlechte Abweichung, mit der später, normalerweise schlecht, umgegangen wird. Bei Offline-First geht der Happy Path bereits davon aus, dass möglicherweise kein Netzwerk vorhanden ist.
Dieser Prämissenwechsel verändert Entscheidungen auf allen Ebenen. Der Bildschirm kann nicht auf einen Fernaufruf angewiesen sein, um Inhalte anzuzeigen. Die Benutzeraktion kann nicht hängen bleiben und auf eine Bestätigung vom Server warten. Der Fluss muss so gestaltet sein, dass er lokal abgeschlossen und später abgeglichen wird.
Wenn Sie auf diese Weise entwerfen, passiert auch dem Online-Benutzer etwas Interessantes. Da alles zuerst lokal reagiert, ist das Erlebnis selbst mit einem hervorragenden Netzwerk schneller. Offline-First ist in der Praxis eine Obermenge der Local-First-Philosophie, die auf den feindseligsten Fall angewendet wird.
Immer zuerst lokal speichern
Der Kern des Ansatzes ist eine einfache Regel: Sämtliches Schreiben erfolgt zuerst auf dem Gerät. Die Schnittstelle liest aus diesem lokalen Speicher und spiegelt die Änderung im laufenden Betrieb wider. Der Benutzer wartet nie darauf, dass der Server das Ergebnis seiner eigenen Aktion sieht.
Im Browser ist hierfür in der Regel IndexedDB der Speicher der Wahl. Dabei handelt es sich um eine in die Seite selbst eingebettete Datenbank, die in der Lage ist, beträchtliche Mengen strukturierter Daten zu speichern und Indizes und Abfragen zu unterstützen. Im Gegensatz zu einfacheren Lösungen übernimmt es das Gewicht einer echten App und nicht nur einige lose Einstellungen.
Die Schnittstellenschicht behandelt nun IndexedDB als Lesequelle. Der Server wird zu einer zweiten Schicht, die durch Synchronisierung unterstützt wird. Dieses Design erfordert Disziplin, da es jetzt zwei Stellen gibt, an denen sich die Matrize befindet, und diese zusammenlaufen müssen, ohne dass der Benutzer die Naht bemerkt.
Bei nativen mobilen Anwendungen ist das Prinzip identisch, lediglich die Speichertechnologie ändert sich. Was zählt, ist die Regel: zuerst lokal, dann remote.
Die Synchronisierungswarteschlange und ihre Details
Wenn das Schreiben offline erfolgt, muss es später an den Server übermittelt werden. Hier kommt die Synchronisierungswarteschlange ins Spiel. Jede Aktion, die Daten ändert, wird als ausstehende Absicht aufgezeichnet, lokal gespeichert und wartet darauf, dass sich das Verbindungsfenster öffnet.
Es scheint einfach, aber der Teufel steckt im Detail. Die Warteschlange muss das Schließen der App überstehen. Wenn die Zustellung fehlschlägt, müssen Sie es erneut versuchen, ohne den bereits gesendeten Text zu duplizieren. Sie müssen die Reihenfolge der Vorgänge einhalten, da das Erstellen und anschließende Bearbeiten eines Datensatzes Dinge sind, die auf dem Server nicht ausgetauscht werden können.
Ich empfehle, jeden in der Warteschlange befindlichen Vorgang nach Möglichkeit als idempotent anzusehen. Idempotenz bedeutet, dass die erneute Ausführung derselben Operation keinen Schaden verursacht. Dies macht die Synchronisierung einer Quelle subtiler Fehler zu einem vorhersehbaren Prozess, da Sie es ohne Angst erneut versuchen können.
Es gibt auch eine Rücksynchronisierung. Während das Gerät offline war, ging die Welt weiter: Andere Benutzer bearbeiteten, der Server wechselte. Wenn die Verbindung wiederhergestellt ist, müssen Sie diese Änderungen übernehmen und mit dem lokalen Status zusammenführen. Und bei der Fusion entsteht das heikelste Problem von allen.
Wenn zwei Geräte dieselben Daten bearbeiten
Stellen Sie sich vor, dass zwei Außendienstmitarbeiter dieselbe Registrierung offline eröffnen. Einer korrigiert die Adresse, der andere korrigiert die Telefonnummer. Beide haben wieder Signal und synchronisieren sich. Welche Version gewinnt? Die naive Antwort, der Letzte, der kommt, überschreibt alles, lässt einen von ihnen stillschweigend die Arbeit verlieren. Inakzeptabel.
Konfliktlösung ist das zentrale Thema eines jeden, der Offline-First ernst nimmt. Die einfachste Strategie, nach Zeit zu gewinnen, funktioniert bei wenig umstrittenen Daten, scheitert jedoch erheblich, wenn konkurrierende Änderungen verschiedene Felder desselben Datensatzes berühren.
Bessere Strategien führen nach Feldern zusammen und behalten die Adressänderung für das eine und die Telefonnummer für das andere bei. Bei komplexeren Strukturen kommen CRDTs ins Spiel, Datentypen, die so konzipiert sind, dass sie beim Zusammenführen automatisch konvergieren, ohne dass ein zentraler Schiedsrichter erforderlich ist. Es lohnt sich zu studieren, wie CRDTs in der Praxis funktionieren, bevor Sie Ihre eigene Zusammenführungslogik erfinden, denn dies ist ein Bereich voller Fallstricke.
Meine ehrliche Empfehlung: Betrachten Sie Konflikte nicht als seltenen Fall und improvisieren Sie am Ende des Projekts. Definieren Sie frühzeitig für jeden Datentyp die Konvergenzregel. Bei dieser Entscheidung handelt es sich sowohl um eine Produktentscheidung als auch um eine technische Entscheidung, da sie definiert, was mit der Arbeit zweier realer Menschen geschieht.
Die Auswirkungen auf die Erfahrung derjenigen, die es nutzen
All dies dient dazu, einem Erlebnis zu dienen, und die Wirkung darauf ist groß. Eine Offline-First-App reagiert mit der Geschwindigkeit der Berührung, nicht mit der Geschwindigkeit des Netzwerks. Für diejenigen, die vor Ort arbeiten, ist dies der Unterschied zwischen einem zuverlässigen Werkzeug und einem Ärgernis, das im schlimmsten Fall ausfällt.
Es besteht jedoch die Notwendigkeit, dem Benutzer gegenüber ehrlich zu sein. Da die Synchronisierung im Hintergrund erfolgt, benötigen Sie klare Statussignale: Was ist passiert, was steht aus, ob etwas schief gelaufen ist. Dies zu verbergen erzeugt ein falsches Sicherheitsgefühl, und falsche Sicherheit ist schlimmer als offene Unsicherheit.
Gute Offline-First-Apps kommunizieren, ohne Angst zu machen. Ein diskreter Hinweis auf anstehende Probleme, eine Warnung, wenn ein Konflikt eine Entscheidung erfordert, eine ruhige Bestätigung, wenn alles synchronisiert ist. Der Benutzer muss sich nicht mit Technik auskennen, aber er muss darauf vertrauen können, dass seine Arbeit nicht in Vergessenheit gerät.
Wo sollte ein Team beginnen?
Wenn Sie ein Team leiten, das die Offline-Lösung zunächst einführen möchte, vermeiden Sie den Fehler, alles auf einmal auszuprobieren. Beginnen Sie mit der lokalen Speicherung und dem Lesen daraus. Führen Sie dann die Synchronisationswarteschlange für Schreibvorgänge ein. Erst dann stellen Sie sich dem Konflikt, und zwar anhand der Art der Daten, nicht auf generische Weise.
Widerstehen Sie auch der Versuchung, Ihre eigene Synchronisierungs-Engine von Grund auf zu erstellen. Es ist ein verlockendes und tiefgreifendes Problem, das jedoch mit ausgereiften Werkzeugen gelöst werden kann. Wenn Sie die Optionen der local-first-ready-Synchronisierungs-Engines verstehen, kann Ihr Team Monate sparen.
Offline-First ist kein technischer Luxus, sondern eine Möglichkeit, die Realität derjenigen zu respektieren, die die Software fernab des Komforts eines perfekten Netzwerks nutzen. Wer nach dieser Prämisse entwirft, liefert Produkte, die genau dann bestehen, wenn es darauf ankommt.
Lesen Sie auch
- Real-Life Location-First: Regierung, Gesundheitswesen und Logistik
- Local-First: Software, die zuerst auf Ihrem Gerät funktioniert
- Sync-Engines: die Tools, die Local-First realisierbar machen
- CRDTs: So synchronisieren Sie serverlose Daten, um Konflikte zu schlichten
- Wann sollte PWA verwendet werden
- [Hybridanwendung Was ist 9