Architetture local-first e CRDT: applicazioni istantanee, anche offline

Nella maggior parte delle applicazioni web ogni azione dell'utente fa lo stesso percorso: il browser invia una richiesta, il server la elabora, il browser attende la risposta e aggiorna l'interfaccia. Funziona finché la rete è veloce e il server risponde. Quando uno dei due rallenta, l'utente guarda uno spinner. Quando la rete manca del tutto, come in un magazzino, in un cantiere o in un furgone, l'applicazione si ferma.

L'approccio local-first ribalta il percorso: i dati vivono prima di tutto sul dispositivo dell'utente, e il server diventa il punto di sincronizzazione.

Come funziona

Il client mantiene una copia dei dati in un database locale nel browser, come IndexedDB o SQLite compilato in WebAssembly con archiviazione su OPFS. Ogni lettura e scrittura avviene lì, quindi l'interfaccia si aggiorna subito. In background, un motore di sincronizzazione scambia le modifiche con il server e con gli altri dispositivi appena la connessione lo permette.

Per l'utente il risultato è un'applicazione che risponde in tempi paragonabili a un programma desktop e che continua a funzionare quando la rete cade.

Il problema dei conflitti e i CRDT

Se due persone modificano lo stesso dato mentre sono offline, cosa succede quando si riconnettono? È la domanda centrale di ogni sistema local-first.

I CRDT (Conflict-free Replicated Data Types) sono strutture dati progettate per rispondere in modo matematico: definiscono regole di fusione tali che, qualunque sia l'ordine in cui arrivano le modifiche, tutte le copie convergono allo stesso stato. Non servono lock sul database centrale e non serve che il server faccia da arbitro per ogni operazione. Librerie mature come Yjs e Automerge implementano questi algoritmi per testi, liste, mappe e documenti strutturati.

I vantaggi concreti

• Interfaccia immediata. Le operazioni locali richiedono pochi millisecondi, perché non dipendono dalla rete né dal carico del server.
• Lavoro offline. Un'interruzione di linea o un problema sul backend non blocca l'operatore: continua a lavorare e le modifiche vengono sincronizzate dopo.
• Collaborazione in tempo reale. Più persone possono lavorare sullo stesso documento o sulla stessa lista, vedendo le modifiche degli altri appena arrivano.
• Meno carico sul server. Molte letture non raggiungono più il backend.

I limiti, da conoscere prima di scegliere

Il local-first non è la risposta giusta per ogni applicazione, e i CRDT non risolvono tutto.

Convergenza non significa correttezza

Un CRDT garantisce che tutte le copie arrivino allo stesso stato, non che quello stato rispetti le regole di business. Se due operatori offline vendono l'ultimo pezzo a magazzino, alla sincronizzazione i dati convergeranno senza errori, ma la giacenza sarà negativa. I vincoli di questo tipo, come disponibilità, saldi e prenotazioni, vanno comunque verificati da un'autorità centrale, oppure gestiti con logiche di riconciliazione esplicite.

Permessi e sicurezza

Se i dati sono sul client, bisogna decidere con cura quali dati sincronizzare verso ciascun utente e validare lato server ogni modifica in arrivo. Il client non può essere considerato affidabile.

Evoluzione dello schema

Aggiornare la struttura dei dati è più complesso quando esistono copie sparse su dispositivi che potrebbero restare offline per giorni con una versione vecchia dell'applicazione.

Spazio e sincronizzazione iniziale

I CRDT conservano metadati sulla storia delle modifiche, che crescono nel tempo. Anche il primo caricamento dei dati su un nuovo dispositivo va progettato con attenzione, e i browser impongono limiti di spazio.

Quando ha senso

Il local-first dà il massimo in applicazioni usate intensamente e spesso in condizioni di rete incerte:

• strumenti operativi sul campo: logistica, manutenzione, rilevazioni, inventari;
• editor e strumenti collaborativi: documenti, note, lavagne, pianificazione;
• gestionali interni in cui la velocità dell'interfaccia incide sulla produttività quotidiana.

È meno indicato per sistemi in cui quasi ogni operazione deve essere validata centralmente in tempo reale, come pagamenti o prenotazioni con disponibilità limitata. Spesso la soluzione migliore è ibrida: local-first per la maggior parte dei dati, conferma dal server per le operazioni critiche.

Come lavoriamo

Quando valutiamo un'architettura local-first partiamo da tre domande: quanto spesso gli utenti lavorano senza rete, quali dati devono essere condivisi in tempo reale e quali regole di business non possono mai essere violate. Le risposte decidono cosa vive sul client, cosa resta sotto il controllo del server e quale strumento di sincronizzazione usare.

Vedi anche: l'archivio dei nostri progetti.

Stai progettando un'applicazione che deve funzionare anche offline? Raccontaci il progetto.