Offline-first v React Native: aplikace bez backendu
Data jen v telefonu ušetří provoz i starosti s GDPR. Co se u offline-first doporučuje a kde jsem sám narazil.
Protokolku, aplikaci na předávací protokoly bytů, jsem postavil bez serveru. Žádná registrace, žádná synchronizace, žádné zpracování osobních údajů na mé straně. Zatím to považuju za nejlepší rozhodnutí projektu — a zároveň za zdroj problémů, které jsem předem nikde nečetl.
Důvod byl původně čistě praktický. Předávací protokol obsahuje fotky bytu, jména a podpisy dvou stran. Ve chvíli, kdy tohle putuje na můj server, stávám se zpracovatelem osobních údajů se vším, co k tomu patří.
Proč se offline-first doporučuje
- Nulové provozní náklady — aplikace se uživí sama.
- Funguje ve sklepě bez signálu, tedy přesně tam, kde se předává.
- Žádný účet znamená o dvě obrazovky méně v onboardingu.
Kde data doopravdy leží
Metadata v lokální databázi, fotky v souborovém systému, vygenerovaná PDF ve sdílené složce. Právě tady jsem narazil na věc, na kterou mě žádná obecná rada dost důrazně neupozornila: neukládat absolutní cesty. Na iOS se kontejner aplikace po aktualizaci mění a uložené odkazy na fotky se rozpadnou.
Ukládejte relativní cesty a absolutní skládejte až při čtení. Tohle jsem se naučil po prvním hlášení „zmizely mi fotky".
Zálohy jsou funkce, ne detail v nastavení
Bez serveru platí, že ztráta telefonu je ztráta dat. Doporučuje se — a dává mi to smysl — mít export všech dat do jednoho souboru vidět v hlavní části aplikace, ne schovaný pod třemi úrovněmi nastavení. Uživatel musí vědět, že zálohu dělá on.
Kdy backend přidat
Hranice, které se držím: ve chvíli, kdy data potřebuje sdílet víc lidí nebo víc zařízení. Do té doby je server hlavně náklad a riziko. Jestli tuhle hranici u téhle aplikace jednou překročím, zatím nevím.
Není to návod pro každou aplikaci — u spousty produktů je server nutnost od prvního dne. Berte to jako popis jednoho scénáře, kde se ho vyplatilo co nejdéle odkládat.