Kodėl pasirinkau offline-first architektūrą
TL;DR
Kai programėlė turi perspėti žmogų tinkamu momentu, patikimumas tampa svarbesnis už technologines tendencijas. „Offline-first“ požiūrį pasirinkau todėl, kad norėjau, jog pagrindinė saugumo funkcija veiktų lokaliai, greitai ir priklausytų nuo kuo mažiau galimų trikdžių.
Šiandien daug programėlių kuriamos taip, kad beveik viskas vyktų per internetą.
Duomenys nuolat siunčiami į serverius, sinchronizuojami realiu laiku, o pati programėlė telefone tampa tik tarsi langas į sistemą.
Toks modelis veikia puikiai daugelyje produktų.
Tačiau kurdamas „SafeWay“ supratau, kad mano atveju svarbiausia buvo ne moderni architektūra, o patikimumas.
Programėlė turėjo atlikti vieną labai konkretų veiksmą — laiku perspėti žmogų, jei jis artėja prie rizikingo ruožo.
Ir kuo daugiau apie tai galvojau, tuo aiškiau supratau vieną dalyką:
nenorėjau, kad ši funkcija priklausytų nuo interneto ryšio kokybės.Kodėl tai buvo svarbiau už patogumą
Silpnas ryšys, laikinas nestabilumas ar vėlavimai yra visiškai normalūs dalykai.
Daugelyje produktų tai nėra didelė problema. Naujienų srautas gali užsikrauti šiek tiek lėčiau. Profilio puslapis gali persikrauti dar kartą. Valdymo skydelis gali trumpam „užstrigti“.
Tačiau perspėjimo sistema veikia kitaip.
Jos vertė tiesiogiai priklauso nuo laiko.
Jeigu programėlė sureaguoja per vėlai arba sprendimas priklauso nuo per daug tarpinių žingsnių, sistema gali veikti techniškai, bet realioje situacijoje būti mažai naudinga.
Būtent ši mintis tapo pagrindiniu projektavimo principu.
Norėjau, kad svarbiausias procesas būtų kuo paprastesnis:
- Lokaliai įkelti rizikos duomenis
- Stebėti naudotojo buvimo vietą realiu laiku
- Palyginti atstumą iki rizikos taškų
- Jei reikia — iškart parodyti perspėjimą
Tai buvo procesas, kuriuo iš tikrųjų galėjau pasitikėti.
Paslėptas paprastesnių sistemų pranašumas
„Offline-first“ nereiškia atsisakyti serverių ar debesijos. Tai tiesiog reiškia, kad svarbiausia produkto dalis turi veikti patikimai net ir tada, kai interneto ryšys nėra idealus.
Ši mintis visą architektūrą padarė paprastesnę ir aiškesnę.
Užuot vertęs programėlę kiekvieną sprendimą priimti per serverį, leidau jai būti pasiruošusiai iš anksto.
Duomenys buvo apdoroti anksčiau. JSON struktūra paruošta naudojimui telefone, o pagrindinė sprendimo logika veikė lokaliai.
Dėl to programėlei nereikėjo kiekvieną kartą kreiptis į tinklą vien tam, kad ji galėtų sureaguoti į naudotojo judėjimą.
1
Lokali duomenų įkrova paleidimo metu
Fast
Rizikos vertinimas įrenginyje
Less
Priklausomybė nuo išorinių gedimo taškų
Ką supratau kaip programuotojas
Man atrodo, kad daug programuotojų, įskaitant ir mane patį, kartais supainioja sudėtingumą su pažangumu.
Pradedame galvoti, kad sistema tampa geresnė tada, kai joje atsiranda daugiau sluoksnių, servisų, integracijų ir tarpusavio ryšių.
Kartais tai tiesa.
Tačiau kartais geriausias sprendimas yra tiesiog tas, kuris pašalina nereikalingą trapumą.
Pagrindinė taisyklė
Kuo svarbesnis momentas, tuo mažiau dalykų turi būti reikalingi, kad sistema suveiktų.
Ši taisyklė naudinga gerokai plačiau nei vien šiai programėlei.
Ji tinka perspėjimams, mokėjimams, registracijos procesams ir bet kuriam momentui, kuriame delsimas ar klaida iš karto griauna pasitikėjimą.
Ką iš to gali pasiimti skaitytojas
Pamoka čia nėra vien ta, kad „offline-first“ požiūris yra geras.
Svarbiausia mintis — architektūra turi atitikti realius produkto poreikius.
Jeigu produktui svarbiausia patikimumas, projektuok patikimumui. Jeigu svarbiausias greitis — projektuok greičiui. O jeigu sistema privalo veikti net ir neidealiomis sąlygomis, pradėk būtent nuo tos realybės, o ne nuo tobulo scenarijaus.
Tai skamba gana akivaizdžiai, tačiau šiandienos technologijos labai lengvai sukuria įspūdį, kad sudėtingesnės ir labiau tarpusavyje sujungtos sistemos automatiškai yra geresnės.
Quote
Sistema nėra išmani vien todėl, kad priklauso nuo daugelio dalių. Ji tampa išmani tada, kai išlieka patikima net ir sugriuvus daliai tų priklausomybių.
„SafeWay“ mane pastūmėjo link paprastesnio požiūrio į inžineriją.
Ne kiekvienam produktui reikia tinklo svarbiausio sprendimo centre. Ne kiekviena funkcija tampa geresnė vien todėl, kad yra labiau išskirstyta. Ir ne kiekviena gera sistema turi atrodyti sudėtinga.
Kartais stipriausia architektūra yra ta, kuri tyliai toliau daro savo darbą net tada, kai ryšys silpnas, o momentas vis dar svarbus.