Offline-first: amikor a telefon az iroda

A jó hálózat feltételezése ritkán állja meg a helyét

A legtöbb app architektúrája hallgatólagosan megbízható hálózatra épül: megnyitáskor lekéri az adatokat, mentéskor a szerverre küldi őket, a kettő között pedig forog a spinner. Aztán jön a valóság: a szerelő a pincéből próbál számlázni, az ingázó alagútban ül, a vidéki munkaterületen egy csík térerő van. Ha az alapfunkciókhoz hálózat kell, ezek a helyzetek mind egy-egy rossz élményt jelentenek – a felhasználók pedig a rossz pillanatokra sokkal tovább emlékeznek, mint a zökkenőmentesekre.

Az offline-first megfordítja a logikát: az elsődleges adatforrás a helyi adatbázis, minden alapművelet helyben és azonnal lefut, a hálózat pedig – ha éppen van – csak szinkronizál és kiegészít. Az Invoice Guru pontosan így működik, helyi Hive-adatréteggel: a számlát kapcsolat nélkül is létre lehet hozni, elmenteni és PDF-be exportálni. Erre azért van szükség, mert egy kivitelező jellemzően pont a számlázás pillanatában van olyan helyen, ahol pocsék a térerő.

Mit ad az offline-first az offline működésen túl

A meglepő az, hogy az offline-first akkor is sokat javít az appon, ha a hálózat tökéletes:

• —Sebesség – minden olvasás és írás helyben történik, így a felületnek soha nem kell a szerver válaszára várnia. Az app nemcsak azonnalinak tűnik, az is.
• —Egyszerű indulás – a Snacker első verziója fiókok, backend és bejelentkezés nélkül jelent meg. Ezzel egyszerre lett rövidebb a fejlesztési idő és kisebb az adatvédelmi kockázat.
• —Beépített adatvédelem – ami soha nem hagyja el az eszközt, azt nem kell átvitel közben védeni, szabályosan tárolni vagy adatvédelmi tájékoztatóban magyarázni.
• —Ellenálló képesség – egyetlen backend-leállás sem viheti magával az alapterméket, mert az alaptermék nem függ backendtől.

Amibe mindez kerül

Az offline-first nem ingyen van. A helyi adatbázis hosszú távú kötelezettséggé válik: a sémamigrációkat a termék teljes élettartama alatt körültekintően kell kezelni, hiszen a felhasználói adatok olyan eszközökön élnek, amelyekhez nem férsz hozzá. Ha később szinkron kerül a rendszerbe, az ütközéskezelés – mi történjen, ha két eszközön szerkesztették ugyanazt a rekordot – valóban nehéz probléma: meg kell tervezni, utólag foltozgatni nem lehet. És vannak termékek, amelyek egyszerűen nem működhetnek offline-first módon: aminek a lényege az együttműködés vagy a valós idejű működés, a chattől az élő piacterekig, annak a hálózat nem kiegészítője, hanem az alapja.

Az ökölszabályunk egyszerű: ha az alapművelet egyetlen eszközön, önmagában is értelmes – számlát írni, edzést naplózni, naplót vezetni –, akkor az offline-first az alapértelmezés. Ha az alapművelet felhasználók közötti párbeszéd, akkor nem.

Indulj helyben, a felhőt érdemeld ki

Ebben egy sorrendi tanulság is rejlik, ami egybevág azzal, ahogyan az MVP-kről általában gondolkodunk: a felhőszinkron, a fiókok és a többeszközös használat funkciók, a funkciókat pedig akkor érdemes hozzáadni, amikor a felhasználók már bizonyították, hogy a termék megérdemli őket. A Snacker teljesen offline indult; a felhőréteg akkor jöhet, ha látszik, hogy az emberek tényleg igénylik. A helyi indulás kicsinek, privátnak és gyorsnak tartja meg az első verziót, a drága infrastruktúráról szóló beszélgetést pedig arra a napra halasztja, amikor tényleg indokolt.