„Să meargă și fără internet” e o cerință care sună simplă și ascunde cea mai delicată decizie de arhitectură dintr-un proiect. Nu pentru că e greu să ții datele local, ci pentru că trebuie să răspunzi la o întrebare pe care nimeni nu vrea să o pună: cine are dreptate când doi oameni au dreptate?
Cele trei niveluri de „offline”
Termenul acoperă lucruri foarte diferite ca dificultate și ca preț.
Nivelul 1: citire offline
Aplicația ține o copie locală a datelor și le poate arăta fără conexiune, dar nu permite modificări. Util pentru cataloage, liste de prețuri, documentație. Simplu de construit, fără riscuri.
Nivelul 2: scriere cu coadă de așteptare
Utilizatorul poate face modificări offline; ele se pun într-o coadă și se trimit când revine conexiunea. Funcționează bine când fiecare om lucrează pe datele lui — un livrator care marchează comenzile lui ca livrate nu se va ciocni niciodată cu altcineva.
Aici e zona în care intră majoritatea aplicațiilor de teren, și e un raport bun între efort și beneficiu.
Nivelul 3: sincronizare bidirecțională cu rezolvare de conflicte
Mai mulți utilizatori modifică aceleași înregistrări, fiecare offline, iar sistemul trebuie să împace versiunile. Aici apar deciziile grele și aici crește bugetul.
Problema conflictelor, pe un exemplu concret
Un depozit cu doi operatori. Internetul cade la 10:00.
- La 10:15, operatorul A schimbă cantitatea produsului X din 50 în 30, pentru că a expediat 20 de bucăți.
- La 10:20, operatorul B schimbă aceeași cantitate din 50 în 45, pentru că a găsit 5 bucăți deteriorate.
- La 10:40 revine internetul.
Care e cantitatea corectă? Răspunsul evident e 25 — ambele operațiuni sunt reale. Dar sistemul nu știe asta dacă a memorat „valoarea nouă e 30″ și „valoarea nouă e 45″. Va alege una și va pierde cealaltă operațiune, tăcut.
Cele patru strategii, cu ce le doare
| Strategie | Cum decide | Riscul | Potrivită pentru |
|---|---|---|---|
| Ultimul câștigă | modificarea cu ora cea mai recentă | pierzi tăcut modificări reale | date fără valoare critică |
| Serverul câștigă | modificările offline se pierd | frustrare mare la utilizatori | date care oricum vin din alt sistem |
| Operațiuni, nu valori | memorezi „scade 20″, nu „pune 30″ | mai complex de construit | stocuri, solduri, contoare |
| Întreabă omul | afișezi ambele versiuni | întrerupe lucrul | documente, texte, comenzi |
A treia strategie e cea corectă pentru orice ține de cantități, și e motivul pentru care merită gândită de la început. Dacă memorezi operațiunea în loc de rezultat, exemplul de mai sus se rezolvă singur: 50 − 20 − 5 = 25.
Ce se decide împreună cu clientul, înainte de cod
Lista asta se parcurge la începutul proiectului, nu la mijloc:
- Care date se pot modifica offline și care nu. Nu tot trebuie să fie disponibil offline. Cu cât lista e mai scurtă, cu atât sistemul e mai sigur.
- Cât timp e realist să stea o stație deconectată. Două ore și două săptămâni sunt probleme complet diferite.
- Ce se întâmplă cu o comandă creată offline care primește un număr. Numerele de comandă trebuie să nu se dubleze; se rezolvă cu prefix per stație sau cu numerotare la server, dar trebuie ales.
- Cine vede conflictele. Operatorul, dispecerul sau nimeni?
- Ce se întâmplă dacă un dispozitiv nu mai revine niciodată online. Datele de pe el se pierd; e acceptabil?
Detalii tehnice care evită probleme reale
- Ceasul dispozitivului nu e de încredere. Dacă strategia depinde de „ultimul câștigă”, iar un calculator are ceasul greșit cu trei ore, rezultatele sunt haotice. Se folosește un contor logic, nu ora locală.
- Sincronizarea trebuie să poată fi reluată. Dacă se întrerupe la jumătate, la reluare nu are voie să retrimită ce a trimis deja.
- Fiecare operațiune primește un identificator unic generat local. Așa serverul recunoaște duplicatele și le ignoră.
- Jurnal de sincronizare vizibil. Când ceva nu se potrivește, cineva trebuie să poată vedea ce s-a trimis, când și cu ce rezultat. Fără el, diagnosticarea e ghicit.
- Testează cu conexiune proastă, nu doar cu conexiune oprită. Cel mai rău caz nu e lipsa internetului, ci internetul care merge intermitent, cu pierderi de pachete.
Cât adaugă la buget
Ca ordin de mărime, față de aceeași aplicație fără capacitate offline:
- Citire offline: +10–15%
- Scriere cu coadă: +25–35%
- Sincronizare bidirecțională cu rezolvare de conflicte: +50–80%
De aceea merită întrebat sincer, la început, de care nivel e nevoie. De multe ori, răspunsul onest e nivelul 2, iar diferența de buget se duce în altceva mai util.