Offline-first architektura

Proč offline-first¶

V kanceláři je Wi-Fi samozřejmost. V terénu je konektivita luxus.

Řidič v podzemní garáži, skladník v betonovém skladu, technik na střeše vysílače, obchodník ve vlaku — vaši uživatelé pracují tam, kde síť není spolehlivá. Aplikace, která při výpadku sítě zobrazí spinner a čeká, je k ničemu. Uživatel se vrátí k papíru.

Offline-first není feature — je to architektonický přístup. Lokální databáze je primární zdroj pravdy. Aplikace reaguje okamžitě na každou interakci. Synchronizace probíhá na pozadí, transparentně. Uživatel nepozná, že je offline — a to je přesně ten cíl.

Kde offline-first řeší reálné problémy¶

• Logistika: Řidiči potvrzují doručení, fotí zásilky, skenují kódy — vše offline. Data se synchronizují při návratu do depa nebo při průjezdu oblastí s pokrytím.
• Field service: Technici vyplňují servisní protokoly, nahrávají fotodokumentaci, čtou technickou dokumentaci — bez závislosti na síti.
• Inventura: Sken tisíců položek za hodinu. Každý záznam okamžitě v lokální DB. Sync po dokončení směny.
• Obchod: Obchodník v terénu má katalog, ceníky, zákaznická data — vše offline. Objednávky se odešlou, jakmile je síť.

Architektura offline-first aplikace¶

Lokální databáze jako primární storage¶

Všechna data potřebná pro práci jsou lokálně. SQLite (Room na Androidu, Core Data / GRDB / SwiftData na iOS) jako primární úložiště. Schéma migrované přes versioning — upgrade databáze při update aplikace bez ztráty dat.

Pro komplexnější scénáře používáme Realm (real-time sync built-in) nebo WatermelonDB (React Native, lazy loading pro velké datasety). Volba závisí na platformě, velikosti dat a sync požadavcích.

Selective sync: Ne všechna data musí být offline. Uživatel dostane data relevantní pro jeho roli, lokaci a aktuální úkoly. Řidič má zásilky pro dnešní trasu, ne celý inventář firmy.

Sync engine¶

Synchronizace je nejtěžší část offline-first architektury. Triviální pro read-only data. Komplexní pro bidirectional sync s více uživateli.

Architektura sync enginu:

1. Change tracking — každá lokální změna se zapíše do outbox tabulky s timestampem a verzí
2. Upload — outbox se odešle na server v pořadí, server vrátí potvrzení nebo konflikt
3. Download — server pošle změny od posledního sync pointu (delta sync)
4. Apply — stažené změny se aplikují do lokální DB
5. Conflict resolution — pokud stejný záznam změnili dva uživatelé, aplikují se business pravidla

Delta sync: Nesynchronizujeme celou databázi. Pouze změny od posledního úspěšného sync. Timestamp-based nebo event-based sync. Komprese payloadu (Protocol Buffers, MessagePack). I na pomalém EDGE připojení proběhne sync za sekundy.

Conflict resolution¶

Dva skladníci editují stejnou inventurní položku offline. Kdo vyhraje?

Strategie podle business kontextu:

• Last-write-wins: Jednoduché, deterministické. Vhodné pro scénáře, kde je nepravděpodobný současný edit (osobní nastavení, individuální formuláře).
• Field-level merge: Pokud uživatel A změnil adresu a uživatel B změnil telefon, obě změny se aplikují. Konflikt jen při změně stejného pole.
• CRDT (Conflict-free Replicated Data Types): Pro collaborative editing — text, seznamy, countery. Matematicky garantovaná konvergence bez centrální autority.
• Custom business rules: „Schválení nadřízeného vždy vyhrává.” „Novější měření nahrazuje starší.” Pravidla definovaná s business analytikem.

Klíčové: uživatel nikdy nepřijde o data. Při neresolvable konfliktu se obě verze zachovají a uživatel rozhodne.

Queue management¶

Operace provedené offline se řadí do perzistentní fronty. Fronta přežije restart aplikace, crash, i update.

Vlastnosti fronty:

• Ordering: Operace se odešlou v pořadí, v jakém byly provedeny
• Retry: Exponential backoff s jitter při selhání (1s → 2s → 4s → 8s + random)
• Idempotence: Každá operace má unikátní ID. Backend je idempotentní — opakovaný request nezpůsobí duplicitu
• Priority: Kritické operace (potvrzení doručení) mají prioritu nad nekritickými (foto)
• Visibility: Uživatel vidí stav fronty — kolik operací čeká, co se právě synchronizuje

Background sync¶

Synchronizace běží na pozadí, i když je aplikace minimalizovaná. iOS Background Tasks API pro pravidelný sync. Android WorkManager pro guaranteed execution. Respektujeme battery a data constraints — sync přes Wi-Fi preferovaný, cellular jen pro kritická data.

Data integrity¶

Offline-first zvyšuje nároky na data integrity. Aplikace musí být odolná proti:

• Partial sync: Server přijal 50 z 100 záznamů, pak spadla síť → transactionální batching
• Schema mismatch: Uživatel A má verzi 2.1, uživatel B má 2.0 → backward-compatible sync protokol
• Clock skew: Zařízení mají různý čas → server-side timestamping pro ordering
• Corrupted local DB: Crash během zápisu → WAL mode, integrity checks, automatic recovery

Testování: Network condition simulation (Charles Proxy, iOS Network Link Conditioner). Chaos testing: random disconnecty, slow networks, packet loss. Automatizované testy v CI ověřují: zero data loss, zero corrupted state, eventual consistency.

Technologický stack¶

iOS: Core Data, SwiftData, GRDB, SQLite, BackgroundTasks, URLSession background transfers.

Android: Room, SQLite, WorkManager, DataStore, OkHttp interceptors.

Cross-platform: WatermelonDB, Realm, PouchDB/CouchDB.

Sync: Custom sync engine, Firebase Realtime DB, Realm Sync, CouchDB replication protocol.

Monitoring: Sync success rate, conflict rate, queue depth, average sync duration — vše v Grafana dashboardech.

Souvisí s