Offline-first to consistency model
Offline-first nie oznacza, że każda funkcja działa bez sieci bez końca. Oznacza, że produkt jawnie określa które akcje mogą działać lokalnie, jak są utrwalane, kiedy się synchronizują i jak rozwiązywane są konflikty.
Zacznij od klas akcji
Podziel akcje na trzy grupy: local-safe, queueable i online-required. Odczyt cached job list może być local-safe. Zamknięcie inspekcji może być queueable. Autoryzacja płatności albo sprawdzenie szybko zmieniającego się inventory może wymagać aktualnej odpowiedzi serwera.
Lokalna operation queue
User action
↓
Validate locally
↓
Persist operation + clientOperationId
↓
Optimistic/local state
↓
Network available?
├─ no → retain queued
└─ yes → submit
↓
server result
↓
reconcile local stateUtrwal operation zanim pokażesz użytkownikowi sukces. Każda mutacja powinna mieć stabilny client operation ID, aby retry po timeout nie stworzył drugiego orderu, taska czy uploadu.
Server-authoritative nie oznacza słabego UX
Serwer może pozostać source of truth, a klient może od razu pokazywać lokalny progress. Kluczowe jest uczciwe komunikowanie pending/synchronized/failed. Field technician może pracować dalej i zsynchronizować się później bez udawania, że backend zaakceptował każdą akcję.
Conflict policy musi być domenowe
„Last write wins” nie jest uniwersalnym rozwiązaniem. Note można często bezpiecznie nadpisać. Inventory allocation, rental booking lub compliance measurement może wymagać dużo bardziej restrykcyjnej reguły. Definiuj conflict policy per entity i operation.
Attachments potrzebują własnego state machine
Zdjęcia, video, signatures i dokumenty są często najcięższymi obiektami offline. Oddziel metadata creation od binary upload i śledź upload state niezależnie, żeby nieudany transfer zdjęcia nie unieważniał całego rekordu biznesowego.
Background synchronization jest opportunistic
Mobile OS ograniczają background execution. Projektuj sync tak, aby potrafił wznowić się po aktywacji aplikacji, odzyskaniu sieci lub przyznaniu background time przez platformę. Nie zakładaj nieskończonego background workera.
Co musi widzieć support
Udostępnij operation ID, device/app version, local timestamp, sync attempts i server result. Inaczej support dostanie „aplikacja mówi, że wysłała” bez dowodu pozwalającego znaleźć miejsce rozjazdu stanu.
Offline-first checklist
- Jawna klasyfikacja akcji.
- Durable local persistence.
- Idempotent mutation IDs.
- Widoczny pending/failed state.
- Domain-specific conflict rules.
- Retry/backoff i replay.
- Attachment lifecycle.
- Observability i support context.
Offline-first ma wartość wtedy, gdy zwiększa odporność realnego workflow operacyjnego — nie wtedy, gdy maksymalizuje liczbę ekranów renderujących się bez Wi-Fi.