Offline-First: progettare per quando Internet non c'è

La maggior parte delle applicazioni tratta la mancanza di connessione come un incidente. Apri una schermata, la rete scompare e appare quell'avviso scoraggiante: niente internet, riprova. L'app si arrende, così come l'utente.

Offline-first inverte questa logica da zero. La premessa è che l'assenza di connessione è lo stato normale e la sua presenza è il vantaggio. Non è pessimismo, è realismo. Chiunque costruisca applicazioni ibride sul campo, mobili o web sa che la rete fallisce più di quanto vorremmo ammettere.

Considera l'offline come una regola, non come un errore

La differenza inizia nella mente del designer. Nel modello comune, il percorso felice è essere online, mentre offline è una brutta deviazione da affrontare in seguito, di solito male. In offline-first, il percorso felice presuppone già che potrebbe non esserci una rete.

Questo cambiamento di premesse modifica le decisioni a tutti i livelli. Lo schermo non può dipendere da una chiamata remota per mostrare il contenuto. L'azione dell'utente non può bloccarsi in attesa di conferma dal server. Il flusso deve essere progettato per essere completato localmente e riconciliato in seguito.

Quando progetti in questo modo, accade qualcosa di interessante anche all'utente online. Poiché tutto risponde prima a livello locale, l'esperienza è più veloce anche con una rete eccellente. Offline-first è, in pratica, un superset della filosofia local-first, applicata al caso più ostile.

Salva prima in locale, sempre

Il cuore dell’approccio è una regola semplice: tutta la scrittura avviene prima sul dispositivo. L'interfaccia legge da questa memoria locale e riflette la modifica al volo. L'utente non aspetta mai che il server veda il risultato della propria azione.

Nel browser, lo spazio di archiviazione preferito per questo è solitamente IndexedDB. Si tratta di un database incorporato nella pagina stessa, in grado di archiviare notevoli volumi di dati strutturati, con supporto per indici e query. A differenza delle soluzioni più semplici, gestisce il peso di un'app reale, non solo alcune preferenze vaghe.

Il livello di interfaccia ora tratta IndexedDB come fonte di lettura. Il server diventa un secondo livello, alimentato dalla sincronizzazione. Questo progetto richiede disciplina, perché ora ci sono due posti in cui vive lo stampo e devono convergere senza che l'utente si accorga della giuntura.

Nelle applicazioni mobili native il principio è identico, cambia solo la tecnologia di archiviazione. Ciò che conta è la regola: prima locale, poi remoto.

La coda di sincronizzazione e i suoi dettagli

Se la scrittura avviene offline, deve essere consegnata al server in un secondo momento. È qui che entra in gioco la coda di sincronizzazione. Ogni azione che modifica i dati viene registrata come intento in sospeso, archiviata localmente, in attesa che la finestra di connessione si alzi.

Sembra semplice, ma il diavolo è nei dettagli. La coda deve sopravvivere alla chiusura dell'app. È necessario riprovare quando la consegna fallisce, senza duplicare ciò che è già stato inviato. Bisogna rispettare l'ordine delle operazioni, perché creare un record e poi modificarlo sono cose che non possono essere scambiate sul server.

Raccomando di considerare ogni operazione in coda come idempotente quando possibile. Idempotenza significa che ripetere la stessa operazione non provoca danni. Ciò rende la sincronizzazione di una fonte di bug sottili un processo prevedibile perché puoi riprovare senza paura.

C'è anche la sincronizzazione posteriore. Mentre il dispositivo era offline, il mondo continuava: altri utenti modificavano, il server cambiava. Quando la connessione ritorna, è necessario apportare queste modifiche e unirle allo stato locale. Ed è proprio dalla fusione che nasce il problema più spinoso di tutti.

Quando due dispositivi modificano gli stessi dati

Immagina due agenti sul campo che aprono la stessa registrazione offline. Uno corregge l'indirizzo, l'altro corregge il numero di telefono. Entrambi hanno di nuovo il segnale e si sincronizzano. Quale versione vince? La risposta ingenua, l'ultima che arriva sovrascrive tutto, fa perdere silenziosamente il lavoro a uno di loro. Inaccettabile.

La risoluzione dei conflitti è il tema centrale di chiunque prenda sul serio l’offline-first. La strategia più semplice, vincente in base al tempo, funziona per pochi dati contestati, ma fallisce gravemente quando modifiche concorrenti toccano campi diversi dello stesso record.

Le strategie migliori si fondono per campo, preservando il cambio di indirizzo per uno e il numero di telefono per l'altro. Per strutture più complesse entrano in gioco i CRDT, tipi di dati progettati per convergere automaticamente una volta fusi, senza bisogno di un arbitro centrale. Vale la pena studiare [come funzionano nella pratica i CRDT] prima di inventare la propria logica di fusione, perché questo è un campo pieno di insidie.

La mia onesta raccomandazione: non trattare il conflitto come un caso raro e improvvisare alla fine del progetto. Definire anticipatamente, per ciascuna tipologia di dati, la regola di convergenza. Questa decisione è una decisione di prodotto tanto quanto di ingegneria, perché definisce cosa succede al lavoro di due persone reali.

##L'impatto sull'esperienza di chi lo utilizza

Tutto questo esiste per servire un’esperienza e l’effetto su di essa è grandioso. Un'app offline risponde alla velocità del tocco, non della rete. Per chi lavora nel settore, questa è la differenza tra uno strumento affidabile e un fastidio che fallisce nel momento peggiore.

Ma è necessario essere onesti con l’utente. Poiché la sincronizzazione avviene in background, sono necessari segnali di stato chiari: cosa è successo, cosa è in sospeso, se qualcosa è andato storto. Nasconderlo crea un falso senso di sicurezza, e la falsa sicurezza è peggiore dell’aperta insicurezza.

Le buone app offline-first comunicano senza spaventare. Un indicatore discreto delle questioni pendenti, un avvertimento quando un conflitto richiede una decisione, una conferma calma quando tutto è sincronizzato. Non è necessario che l'utente capisca l'ingegneria, ma deve avere fiducia che il suo lavoro non svanirà.

Da dove dovrebbe iniziare una squadra

Se guidi un team che sta per adottare prima l'offline, evita l'errore di provare tutto in una volta. Inizia con l'archiviazione locale e leggi da essa. Quindi introdurre la coda di sincronizzazione per le scritture. Solo allora affrontare il conflitto, e affrontarlo per tipologia di dati, non in modo generico.

Resisti anche alla tentazione di costruire da zero il tuo motore di sincronizzazione. È un problema seducente e profondo, ma risolto con strumenti maturi. Comprendere le opzioni dei motori di sincronizzazione local-first-ready può far risparmiare mesi al tuo team.