Offline arbeiten, ohne Chaos: Wie Local-First-Architektur Konflikte löst

Stell dir vor: Ein Außendienstmitarbeiter bearbeitet auf einer Baustelle einen Auftrag — ohne Internetverbindung. Gleichzeitig ändert eine Kollegin im Büro denselben Datensatz. Wenn beide wieder online sind: Was passiert?

Genau an dieser Stelle scheitern die meisten Apps. Entweder verliert einer der beiden seine Änderungen, oder die App zeigt einen kryptischen Fehler. Bei smallstack passiert etwas anderes — und der Grund dafür steckt tief in der Architektur.

Was "Local-First" wirklich bedeutet

"Offline-fähig" und "Local-First" klingen ähnlich, sind aber grundverschieden.

Eine offline-fähige App speichert Daten manchmal lokal — als Notlösung, wenn keine Verbindung besteht. Sobald die Verbindung zurückkommt, holt sie frische Daten vom Server und überschreibt alles Lokale. Einfach, aber brutal: Deine lokalen Änderungen sind weg.

Eine Local-First-App dreht das Prinzip um. Dein Gerät ist der primäre Speicherort. Änderungen passieren zuerst lokal, sofort, ohne Wartezeit. Der Server ist nicht der Anker — er ist der Synchronisierungspunkt zwischen allen Geräten. Diese Umkehrung klingt nach einem Detail, verändert aber alles.

smallstack ist von Grund auf Local-First gebaut. Das bedeutet: Keine Ladebalken beim Tippen. Keine "Verbindung verloren"-Meldungen mitten in der Arbeit. Kein Datenverlust, wenn das WLAN ausfällt.

Das Kernproblem: Was passiert, wenn beide gleichzeitig schreiben?

In einer zentralisierten App ist das einfach geregelt: Wer zuletzt speichert, gewinnt. Das mag für einfache Anwendungsfälle reichen — aber es bedeutet, dass einer der Nutzer seine Arbeit verliert, ohne es zu merken.

Local-First-Systeme brauchen eine intelligentere Lösung. Hier kommen CRDTs ins Spiel.

CRDTs: Konfliktlösung durch Mathematik

CRDT steht für Conflict-free Replicated Data Type — auf Deutsch: konfliktfreier, replizierter Datentyp. Das klingt sperrig, ist aber ein elegantes Konzept.

Ein CRDT ist eine Datenstruktur, die so gestaltet ist, dass Änderungen aus verschiedenen Quellen immer zu einem konsistenten Ergebnis zusammengeführt werden können — ohne menschliche Intervention, ohne Konfliktdialoge, ohne Datenverlust.

Das Geheimnis: Jede Änderung wird nicht als "der neue Wert" gespeichert, sondern als Operation — als Beschreibung dessen, was getan wurde. Statt "Setze den Wert auf X" heißt es "Addiere 5" oder "Hänge diesen Text an Zeile 3 an". Operationen aus verschiedenen Quellen können mathematisch in beliebiger Reihenfolge kombiniert werden und ergeben immer dasselbe Ergebnis.

Ein konkretes Beispiel

Anna und Ben arbeiten beide am Profil eines Kunden — offline.

• Anna ändert die Telefonnummer des Kunden.
• Ben fügt eine Notiz zum Kunden hinzu.

Wenn beide synchronisieren, sind beide Änderungen vorhanden. Kein Konflikt, weil es sich um verschiedene Felder handelt.

Was passiert, wenn beide dasselbe Textfeld bearbeiten? Hier nutzt smallstack Last-Write-Wins für einfache Felder — mit Zeitstempel. Für komplexere Strukturen wie Listen oder gemeinsam bearbeitete Textfelder kommen CRDT-Algorithmen zum Einsatz, die beide Änderungen intelligent zusammenführen.

Wie smallstack das konkret umsetzt: SignalDB

smallstack verwendet SignalDB — eine reaktive Datenbank für den Browser, die speziell für Local-First-Anwendungen entwickelt wurde. Das Besondere: SignalDB arbeitet mit inkrementeller Synchronisierung.

Das bedeutet:

• Bei Verbindungsaufnahme werden nicht alle Daten neu geladen, sondern nur die Änderungen seit dem letzten Sync.
• Jede Änderung hat einen updatedAt-Zeitstempel. Der Server weiß, was du bereits hast — und schickt nur, was neu ist.
• Änderungen fließen in Echtzeit zu allen verbundenen Geräten, ohne manuelle Aktualisierung.

Das ist nicht nur eleganter — es ist auch schneller und verbraucht deutlich weniger Bandbreite als klassische Polling-Ansätze.

Was das in der Praxis bedeutet

Für den Außendienstmitarbeiter: Er öffnet die App auf der Baustelle — kein Internet. Er bearbeitet Aufträge, macht Fotos, trägt Zeiten ein. Alles funktioniert, als wäre er online. Wenn er abends zurück ins Büro fährt, synchronisiert sich alles automatisch im Hintergrund. Keine Aktion erforderlich.

Für das Büro: Änderungen erscheinen in Echtzeit bei allen Kollegen, die gerade online sind — ohne "Seite neu laden". Wie Google Docs, aber für alle Geschäftsdaten.

Für den IT-Verantwortlichen: Keine eigene Offline-Lösung entwickeln, keine komplexe Synchronisierungslogik. Das ist in der Plattform gelöst.

Warum kaum eine andere No-Code-Plattform das kann

Offline-First ist technisch anspruchsvoll. Klassische SaaS-Tools wie Airtable, Monday.com oder Notion sind um einen zentralen Server herum gebaut. Offline-Unterstützung nachzurüsten ist fast unmöglich — man müsste das Fundament neu bauen.

smallstack hat das richtig gemacht: Local-First war von Anfang an Teil der Architekturentscheidung, nicht ein nachträgliches Feature. Das ist der Unterschied zwischen "funktioniert im Netzwerk, überleben im Keller" und "funktioniert überall, immer".

Für wen ist das relevant?

• Bauunternehmen und Handwerksbetriebe: Baustellen haben selten stabiles WLAN.
• Außendienstteams: Techniker, Pflegedienste, Lieferfahrer — überall mit schlechtem Empfang.
• Veranstaltungsmanagement: Eventgelände, Messen, Hallen ohne verlässliches Netz.
• Ländliche Betriebe: Landwirtschaft, Forstbetriebe, Windparks.
• Jeder, der Züge nutzt: Daten bearbeiten, während die Verbindung kommt und geht — kein Problem.

Fazit

Local-First ist kein Marketing-Begriff — es ist eine fundamentale Designentscheidung, die sich auf alles auswirkt: Geschwindigkeit, Zuverlässigkeit, Nutzererfahrung und Datenintegrität. CRDTs und inkrementelle Synchronisierung mit SignalDB machen es möglich, dass smallstack in Umgebungen funktioniert, in denen andere Apps schlicht aufgeben.

Wenn dein Team mobil arbeitet oder du weißt, dass die Netzwerkverbindung nicht immer stabil ist — probier smallstack aus. Die erste Testumgebung ist kostenlos.

---

Technisch interessiert? Im Artikel auf dev.to gehen wir tiefer in die Architektur — mit Codebeispielen und dem genauen Synchronisierungsprotokoll.