La tua app per autisti deve funzionare in una gabbia di Faraday

L'esercizio più utile che facciamo con un nuovo cliente logistico è il test dell'ascensore. Si prende il telefono dell'autista, si entra nell'ascensore merci alla banchina di carico, si chiudono le porte e si osserva l'app.

Se l'app diventa uno spinner, si blocca, perde il punto in cui si trovava l'utente, o — il fallimento più comune — scarta silenziosamente la scansione che l'autista ha appena eseguito, l'app non è pronta per la produzione. Gli autisti passano una parte significativa della loro giornata in scatole d'acciaio, edifici in cemento, zone morte rurali e tunnel. La connettività non è una proprietà che hanno. È una proprietà che a volte hanno.

Questo è il vincolo reale. Costruire tenendolo in conto non è ingegneria di lusso; è l'unico tipo che viene rilasciato.

I tre modi di fallire che colpiscono ogni team

Dopo abbastanza engagement logistici, tre modalità di fallimento emergono ripetutamente.

La scrittura ottimistica che non era tale. L'autista scansiona un pacco. L'app mostra "scansionato." Il server, a causa di un'interruzione di rete, non ha mai ricevuto la scansione. L'autista crede che il pacco sia nel sistema; il sistema non lo sa. Il pacco arriva alla fermata successiva e nessuno sa cosa farne. La causa principale: l'app ha mostrato il successo sulla base di un'azione locale, senza conferma dal server, e senza che l'autista potesse capire la differenza.

Il login che ha bisogno della rete. Un autista si presenta all'inizio del turno e il telefono ha perso la sessione. La schermata di login deve chiamare il server di autenticazione. L'autista è nel parcheggio, con due tacche di copertura che scendono a zero ogni volta che il camion si muove. Il turno non può iniziare. Ogni minuto di questo è tempo retribuito, e il telefono del dispatcher sta suonando.

La coda "sync later" che perde dati. Molti team costruiscono il supporto offline accodando azioni in locale e sincronizzando quando la rete torna. Funziona finché la coda non supera ciò che il dispositivo può contenere, oppure l'utente chiude l'app e la coda viene persa, oppure il codice di sincronizzazione ha un bug e scarta silenziosamente degli elementi. L'autista fa il proprio lavoro correttamente. I dati non arrivano. L'autista viene incolpato.

Cosa richiede davvero l'offline-first

Offline-first non è una funzionalità da aggiungere. È una proprietà dell'architettura, e o l'app è costruita attorno ad essa fin dal giorno uno oppure no.

La forma che funziona:

Lo store locale è la fonte di verità per la sessione. Quando l'autista scansiona un pacco, la scansione viene scritta immediatamente in uno store locale durevole, e l'interfaccia legge da quello store. La sincronizzazione con il server è un processo separato che gira quando può. L'interfaccia non aspetta il server; mostra lo stato locale, che è lo stato reale che l'autista vive.

Ogni azione ha un ID generato lato client. UUID, generati sul dispositivo prima che l'azione venga eseguita. Questo significa che la stessa azione può essere riprovata indefinitamente in modo sicuro senza creare duplicati lato server, e significa che l'azione esiste nello store locale con un'identità stabile anche prima che il server l'abbia mai vista.

La sincronizzazione è visibile all'utente, non nascosta. Un piccolo indicatore: "12 azioni in attesa, ultima sincronizzazione 4 minuti fa." Gli autisti lo trovano rassicurante. Vogliono sapere se il loro lavoro è stato registrato. Nascondere lo stato di sincronizzazione in nome della pulizia UX è ciò che porta allo scenario "scansionato, ma non davvero."

I token di autenticazione hanno una lunga validità offline. Si accede una volta, si ottiene un token che sopravvive a un periodo offline di più giorni. Il token viene aggiornato in background ogni volta che la rete è disponibile. Un'interruzione di rete al momento del rinnovo del token va trattata come un non-evento; solo un token effettivamente scaduto senza rinnovo dovrebbe forzare un nuovo login. Questa singola modifica elimina il fallimento più comune all'inizio del turno.

Cosa cambia lato server

L'offline-first è di solito inquadrato come una proprietà lato client. Ha anche conseguenze per il server.

Gli endpoint del server devono essere idempotenti. Il client riproverà. I retry avverranno giorni dopo l'originale. L'originale potrebbe o non potrebbe essere stato ricevuto. L'endpoint deve gestire "ho già elaborato questa azione con questo ID generato dal client" in modo elegante, restituendo lo stesso risultato invece di creare un duplicato o rifiutare la richiesta.

Il tempo sul server non è lo stesso del tempo sul client. L'azione è stata eseguita alle 9:14 ora locale dell'autista, ma il server la registra alle 11:47 dopo che l'autista è tornato in copertura. Ogni record ha bisogno di entrambi i timestamp. I report che li confondono indurranno in errore il business.

La struttura dei dati deve tollerare modifiche in consistenza eventuale. Un autista potrebbe segnare un pacco come consegnato, poi il supervisore potrebbe segnarlo come reso, prima che l'azione dell'autista sia sincronizzata. La risoluzione dei conflitti deve essere deliberata, non "vince l'ultima scrittura per caso." Di solito la regola è "l'azione dell'autista ha priorità nel turno, l'azione del supervisore ha priorità dopo il turno," ma dipende dal business.

Il test pragmatico

Se state valutando una piattaforma logistica — acquistandola o costruendola — eseguite il test dell'ascensore prima di tutto il resto. Prendete l'app, prendete il telefono, chiudete le porte dell'ascensore, eseguite un'attività normale. Vedete cosa succede.

Le piattaforme che superano questo test di solito vanno bene. Quelle che lo falliscono lo falliranno in produzione ogni giorno, e incolperanno la rete quando lo faranno.