Musí to tak byť? Nie.
Práve na tento problém sa zameriava prístup offline-first. Jeho cieľom je, aby aplikácia dokázala fungovať aj bez stabilného internetového pripojenia – aspoň v tých funkciách, ktoré používateľ potrebuje najviac. Neznamená to, že každá funkcia musí fungovať offline. Znamená to, že výpadok internetu nemusí automaticky znamenať koniec práce s aplikáciou.
Ako to funguje v praxi?
Dáta priamo v zariadení
Základom offline-first aplikácie je lokálne ukladanie dát. Namiesto toho, aby aplikácia pri každom otvorení obrazovky žiadala všetky informácie zo servera, uchováva potrebné údaje aj priamo v zariadení.
Môže ísť napríklad o uložené články, úlohy, poznámky alebo informácie, ktoré používateľ nedávno otvoril. Dáta sa môžu ukladať do lokálnej databázy, do súborov alebo do inej formy úložiska v zariadení.
Keď používateľ aplikáciu otvorí bez internetu, môže pracovať s tým, čo už má uložené. Aplikácia tak nemusí čakať na odpoveď servera a môže zobrazovať dostupné informácie aj pri slabom pripojení.
Dôležitý je však jeden rozdiel: lokálne uložené dáta nemusia byť aktuálne. Ak niekto medzičasom zmenil informácie na serveri alebo na inom zariadení, aplikácia o tom zatiaľ nemusí vedieť. Preto nestačí dáta iba uložiť. Treba vyriešiť aj ich aktualizáciu.
Čo ak používateľ zmení niečo bez internetu?
Predstavme si aplikáciu na správu úloh. Používateľ v metre vytvorí novú úlohu, nastaví jej termín a uloží ju.
Ak aplikácia vyžaduje neustále pripojenie, môže uloženie zlyhať. V offline-first aplikácii sa však zmena môže najskôr uložiť do zariadenia. Používateľ vidí svoju novú úlohu a môže pokračovať v práci.
Aplikácia si zároveň zaznamená, že túto zmenu ešte musí odoslať na server.
Na to slúži offline queue, teda front čakajúcich operácií. Predstavte si ju ako zoznam úloh, ktoré aplikácia potrebuje vybaviť, len čo bude mať opäť prístup k internetu.
Keď sa pripojenie obnoví, aplikácia začne čakajúce zmeny odosielať. Ak sa niektorá operácia nepodarí, môže ju skúsiť zopakovať.
Nie každá akcia sa však dá bezpečne odložiť. Napríklad bankový prevod, ktorý vyžaduje potvrdenie servera, nemožno považovať za úspešne dokončený len preto, že používateľ stlačil tlačidlo. Pri takýchto operáciách musí aplikácia jasne rozlišovať medzi požiadavkou čakajúcou na spracovanie a skutočne potvrdenou transakciou.
Synchronizácia: keď sa zariadenie opäť pripojí
Keď sa internet vráti, aplikácia potrebuje zosúladiť lokálne uložené dáta s tými na serveri. Tento proces sa nazýva synchronizácia.
V najjednoduchšom prípade aplikácia odošle zmeny vykonané offline a stiahne si najnovšie údaje zo servera. V praxi však môže byť synchronizácia zložitejšia, najmä ak používateľ pracoval na viacerých zariadeniach.
Predstavme si, že si ráno v mobile upraví názov úlohy. Neskôr, na inom zariadení, tú istú úlohu upraví aj kolega. Obe zariadenia mohli pracovať s rovnakou pôvodnou verziou, ale každé ju zmenilo inak.
Čo sa stane, keď sa obe zariadenia pripoja na internet?
Konflikty: keď sa dve zmeny stretnú
Ak sa tá istá informácia zmení na viacerých miestach ešte pred synchronizáciou, aplikácia musí rozhodnúť, ako zmeny zosúladiť. Tento proces sa nazýva riešenie konfliktov (conflict resolution).
Jednou z možností je pravidlo last write wins – vyhrá posledná zmena podľa zvoleného časového údaja. Nie je to však univerzálne najlepšie riešenie. Závisí od typu dát a od toho, čo sa stane, ak sa niektorá zmena prepíše.
Pri jednoduchom nákupnom zozname môže byť automatické pravidlo dostatočné. Pri spoločnom dokumente alebo dôležitých firemných záznamoch môže byť potrebné zmeny zlúčiť alebo používateľovi ukázať konflikt a nechať ho rozhodnúť.
Preto sa pravidlá synchronizácie a riešenia konfliktov oplatí navrhnúť už pri plánovaní aplikácie. Ak sa nechajú až na neskôr, môžu viesť k strate údajov alebo k nepredvídateľnému správaniu.
Čo ak internet stále vypadáva?
Ani po obnovení pripojenia nemusí všetko fungovať na prvý pokus. Sieť môže byť nestabilná, server môže dočasne neodpovedať alebo môže požiadavka zlyhať z iného dôvodu.
Preto offline-first aplikácie potrebujú aj spoľahlivé opakované pokusy (retry). Pri dočasných chybách môže aplikácia požiadavku skúsiť odoslať znova, často s postupne dlhšími prestávkami medzi pokusmi. Takýto prístup sa nazýva exponential backoff.
Dôležité je však neopakovať bez rozmyslu každú požiadavku. Ak server odmietne akciu pre nedostatočné oprávnenia, samotné čakanie problém nevyrieši. A pri operáciách, ktoré menia dáta, treba zabrániť tomu, aby opakovaný pokus vykonal tú istú akciu dvakrát.
Aplikácia by tiež mala používateľovi ukázať, čo sa deje. Je zmena uložená iba v zariadení? Čaká na odoslanie? Bola už potvrdená serverom? Jasný stav je oveľa užitočnejší než neurčitá chybová hláška.
Offline-first nie je len technická vychytávka
Offline-first prístup môže výrazne zlepšiť používateľskú skúsenosť, najmä pri cestovaní, práci v teréne alebo v oblastiach s nespoľahlivým pripojením. Aplikácia môže reagovať rýchlejšie, používateľ nemusí opakovane zadávať stratené údaje a krátky výpadok internetu ho nemusí zastaviť.
Zároveň si tento prístup vyžaduje premyslené rozhodnutia. Ktoré údaje majú byť dostupné offline? Ktoré zmeny možno bezpečne uložiť a odoslať neskôr? Ako sa riešia konflikty? Čo sa stane, ak sa synchronizácia opakovane nepodarí?
Odpovede sa líšia podľa typu aplikácie. Offline-first aplikácia na poznámky má iné požiadavky než banková aplikácia alebo nástroj na spoluprácu v reálnom čase.
Dobrá offline-first aplikácia nesľubuje, že internet nikdy nebude potrebovať. Zabezpečí však, aby jeho výpadok používateľa zbytočne nezastavil.
A práve to je rozdiel medzi aplikáciou, ktorá funguje iba v ideálnych podmienkach, a aplikáciou navrhnutou pre skutočný svet.
