Nuovo tentativo con le richieste quando sei di nuovo online

Quando si effettuano richieste a un server web, è possibile che non si verifichi un errore. La connessione dell'utente potrebbe essere interrotta o il server remoto non è attivo.

Anche se questa documentazione è incentrata principalmente sulla gestione delle richieste GET in un service worker, potrebbero entrare in gioco altri metodi come POST, PUT o DELETE. Questi metodi vengono spesso utilizzati per comunicare con le API di backend al fine di fornire dati per un'app web. Quando queste richieste non vanno a buon fine in assenza di un service worker, devono essere tentate di nuovo manualmente dall'utente quando sono di nuovo online. Questa operazione non è sempre un'attività che gli utenti si ricordano sempre di fare.

Se questo è il caso della tua applicazione (e se è presente un service worker), dovresti riprovare a inviare le richieste non riuscite quando l'utente sarà di nuovo online. L'API BackgroundSync offre una soluzione a questo problema. Quando un service worker rileva una richiesta di rete non riuscita, può registrarsi per ricevere un evento sync quando il browser rileva che la connettività è tornata. L'evento sync può essere consegnato anche se l'utente è uscito dalla pagina in cui l'ha registrato, rendendolo più efficace rispetto ad altri metodi per riprovare a eseguire le richieste non riuscite.

Workbox astrae questa API con il modulo workbox-background-sync, semplificando l'utilizzo dell'API BackgroundSync con altri moduli Workbox. Implementa inoltre una strategia di riserva per i browser che non supportano ancora BackgroundSync.

Utilizzo di base

L'elemento BackgroundSyncPlugin viene esportato dal modulo workbox-background-sync e può essere utilizzato per mettere in coda le richieste non riuscite e riprovare quando vengono attivati futuri eventi sync:

import {BackgroundSyncPlugin} from 'workbox-background-sync';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

const bgSyncPlugin = new BackgroundSyncPlugin('myQueueName', {
  maxRetentionTime: 24 * 60 // Retry for max of 24 Hours (specified in minutes)
});

registerRoute(
  /\/api\/.*\/*.json/,
  new NetworkOnly({
    plugins: [bgSyncPlugin]
  }),
  // An optional third parameter specifies the request method
  'POST'
);

In questo caso, BackgroundSyncPlugin viene applicato a una route che corrisponde alle richieste POST a una route API che recupera dati JSON. Se l'utente è offline, BackgroundSyncPlugin riproverà a inviare la richiesta quando sarà di nuovo online, ma solo per massimo un giorno.

Utilizzo avanzato

workbox-background-sync fornisce anche una classe Queue, a cui puoi creare un'istanza e a cui puoi aggiungere richieste non riuscite. Come nel caso di BackgroundSyncPlugin, le richieste non riuscite vengono archiviate in IndexedDB e provate quando il browser ritiene che la connettività sia ripristinata.

Creazione di una coda

Per creare una coda, crea un'istanza di un oggetto Queue con una stringa che rappresenta il nome della coda:

import {Queue} from 'workbox-background-sync';

const queue = new Queue('myQueueName');

Il nome della coda viene utilizzato come parte del nome del tag creato con il metodo register() fornito dal metodo globale SyncManager. È anche il nome utilizzato per l'archivio oggetti fornito dal database IndexedDB.

Aggiunta di richieste alla coda

Dopo aver creato l'istanza Queue, puoi aggiungere richieste non riuscite utilizzando il metodo pushRequest():

import {Queue} from 'workbox-background-sync';

const queue = new Queue('myQueueName');

self.addEventListener('fetch', (event) => {
  // Add in your own criteria here to return early if this
  // isn't a request that should use background sync.
  if (event.request.method !== 'POST') {
    return;
  }

  const bgSyncLogic = async () => {
    try {
      const response = await fetch(event.request.clone());
      return response;
    } catch (error) {
      await queue.pushRequest({request: event.request});
      return error;
    }
  };

  event.respondWith(bgSyncLogic());
});

Una volta aggiunte alla coda, le richieste riproveranno automaticamente quando il service worker riceve l'evento sync perché il browser ritiene che la rete sia di nuovo disponibile. I browser che non supportano l'API BackgroundSync riproveranno la richiesta a ogni avvio del service worker, il che è un modo meno efficace per ritentare una richiesta non riuscita, ma si tratta di una sorta di fallback.

Test di workbox-background-sync in corso...

Testare il comportamento della sincronizzazione in background può essere difficile, ma può essere eseguito in Chrome DevTools. L'approccio migliore attuale è simile al seguente:

  1. Carica una pagina di registrazione del service worker.
  2. Disattiva la connessione di rete del computer o disattiva il server web. Non utilizzare l'opzione offline in Chrome DevTools. La casella di controllo della modalità offline influisce solo sulle richieste della pagina, ma le richieste dei service worker continueranno ad andare avanti.
  3. Effettua richieste di rete che devono essere in coda con workbox-background-sync. Puoi controllare le richieste che sono state messe in coda cercando in Chrome DevTools > Application > IndexedDB > workbox-background-sync > requests.
  4. Ora ripristina la connettività di rete o riattiva il server web.
  5. Forza un evento sync in anticipo andando su Chrome DevTools > Application > Service Workers. Inserisci il nome del tag workbox-background-sync:<your queue name>, dove <your queue name> è il nome della coda impostata.
  6. Fai clic sul pulsante "Sincronizza".
    Uno screenshot dell&#39;utilità di sincronizzazione in background nel riquadro dell&#39;applicazione dei DevTools di Chrome. L&#39;evento di sincronizzazione è specificato per una coda di &quot;myQueueName&quot; del modulo &quot;workbox-background-sync&quot;.
  7. A questo punto dovresti vedere le richieste di rete non riuscite in precedenza che sono state tentate di nuovo e andate a buon fine. Di conseguenza, l'archivio IndexedDB dovrebbe essere vuoto, poiché le richieste sono state riprodotte correttamente.

Conclusione

L'utilizzo di workbox-background-sync per ritentare le richieste di rete non riuscite può essere un ottimo modo per migliorare l'esperienza utente e l'affidabilità della tua app, ad esempio consentire agli utenti di inviare nuovamente le richieste API non riuscite in modo da non perdere i dati che volevano inviare alla tua API. Può essere utilizzato anche per colmare le lacune nei tuoi dati, ad esempio nell'analisi. Di fatto, il modulo workbox-google-analytics utilizza workbox-background-sync in background per riprovare le richieste non riuscite di inviare dati a Google Analytics.

Qualunque sia il tuo caso d'uso, workbox-background-sync semplifica questo tipo di attività, migliorando l'esperienza di sviluppo e offrendoti maggiori opportunità per migliorare l'esperienza utente e le funzionalità della tua applicazione web.