Comunicazione bidirezionale con i service worker

Andrew Guan

Demián Renzulli

In alcuni casi, un'app web potrebbe dover stabilire un canale di comunicazione bidirezionale tra la pagina e il service worker.

Ad esempio, in una PWA di podcast è possibile creare una funzionalità per consentire all'utente di scaricare le puntate per l'ascolto offline e consentire al service worker di tenere la pagina regolarmente informata sull'avanzamento, in modo che il thread principale possa aggiornare l'interfaccia utente.

In questa guida esploreremo i diversi modi per implementare una comunicazione bidirezionale tra il contesto Window e il contesto del service worker, esplorando diverse API, la libreria Workbox e alcuni casi avanzati.

Nota: consulta la panoramica dei worker per una spiegazione generale di quando utilizzare i web worker rispetto ai service worker e il resto della serie Comunicare con i worker per guide su altri casi d'uso comuni.

Utilizzo di Workbox

workbox-window è un insieme di moduli della libreria Workbox destinati a essere eseguiti nel contesto della finestra. La classe Workbox fornisce un metodo messageSW() per inviare un messaggio al service worker registrato dell'istanza e attendere una risposta.

Il seguente codice della pagina crea una nuova istanza Workbox e invia un messaggio al service worker per ottenere la sua versione:

const wb = new Workbox('/sw.js');
wb.register();

const swVersion = await wb.messageSW({type: 'GET_VERSION'});
console.log('Service Worker version:', swVersion);

Il service worker implementa un listener di messaggi sull'altro lato e risponde al service worker registrato:

const SW_VERSION = '1.0.0';

self.addEventListener('message', (event) => {
  if (event.data.type === 'GET_VERSION') {
    event.ports[0].postMessage(SW_VERSION);
  }
});

Dietro le quinte, la libreria utilizza un'API del browser che esamineremo nella prossima sezione, Message Channel, ma astrae molti dettagli di implementazione, semplificandone l'utilizzo e sfruttando l'ampio supporto del browser di questa API.

Utilizzo delle API del browser

Se la libreria Workbox non è sufficiente per le tue esigenze, sono disponibili diverse API di livello inferiore per implementare la comunicazione "bidirezionale" tra pagine e service worker. Presentano alcune somiglianze e differenze:

Analogie:

• In tutti i casi, la comunicazione inizia da un lato tramite l'interfaccia postMessage() e viene ricevuta dall'altro lato implementando un gestore message.
• In pratica, tutte le API disponibili ci consentono di implementare gli stessi casi d'uso, ma alcune potrebbero semplificare lo sviluppo in alcuni scenari.

Differenze:

• Hanno modi diversi di identificare l'altro lato della comunicazione: alcuni utilizzano un riferimento esplicito all'altro contesto, mentre altri possono comunicare in modo implicito tramite un oggetto proxy di cui viene creata un'istanza su ciascun lato.
• Il supporto dei browser varia tra questi.

API Broadcast Channel

Browser Support

• 54
• 79
• 38
• 15.4

Source

L'API Broadcast Channel consente la comunicazione di base tra i contesti di navigazione tramite gli oggetti BroadcastChannel.

Per implementarlo, innanzitutto ogni contesto deve creare un'istanza di un oggetto BroadcastChannel con lo stesso ID e inviare e ricevere messaggi da questo oggetto:

const broadcast = new BroadcastChannel('channel-123');

L'oggetto BroadcastChannel espone un'interfaccia postMessage() per inviare un messaggio a qualsiasi contesto di ascolto:

//send message
broadcast.postMessage({ type: 'MSG_ID', });

Qualsiasi contesto del browser può ascoltare i messaggi tramite il metodo onmessage dell'oggetto BroadcastChannel:

//listen to messages
broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process message...
  }
};

Come puoi vedere, non esiste un riferimento esplicito a un contesto particolare, quindi non è necessario ottenere prima un riferimento al service worker o a un client specifico.

Lo svantaggio è che, al momento della stesura di questo articolo, l'API è supportata da Chrome, Firefox ed Edge, ma altri browser, come Safari, non la supportano ancora.

API client

Browser Support

• 40
• 17
• 44
• 11.1

Source

L'API Client ti consente di ottenere un riferimento a tutti gli oggetti WindowClient che rappresentano le schede attive controllate dal service worker.

Poiché la pagina è controllata da un singolo service worker, ascolta e invia messaggi al service worker attivo direttamente tramite l'interfaccia serviceWorker:

//send message
navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
});

//listen to messages
navigator.serviceWorker.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process response
  }
};

Allo stesso modo, il service worker rimane in ascolto dei messaggi implementando un listener onmessage:

//listen to messages
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //Process message
  }
});

Per comunicare con uno dei suoi client, il service worker ottiene un array di oggetti WindowClient eseguendo metodi come Clients.matchAll() e Clients.get(). Quindi può postMessage() uno qualsiasi di questi:

//Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    //Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

Client API è una buona opzione per comunicare facilmente con tutte le schede attive da un service worker in modo relativamente semplice. L'API è supportata da tutti i principali browser, ma non tutti i suoi metodi potrebbero essere disponibili, quindi assicurati di verificare il supporto del browser prima di implementarla nel tuo sito.

Nota: in questa guida ci concentriamo principalmente sui casi d'uso relativi all'affidabilità. Un altro utilizzo interessante di questa API è la sincronizzazione dei dati tra i documenti tramite un service worker. Per saperne di più, guarda questa puntata di HTTP 203.

Canale messaggi

Browser Support

• 2
• 12
• 41
• 5

Source

Message Channel richiede la definizione e il passaggio di una porta da un contesto all'altro per stabilire un canale di comunicazione bidirezionale.

Per inizializzare il canale, la pagina crea un'istanza di un oggetto MessageChannel e la utilizza per inviare una porta al service worker registrato. La pagina implementa anche un listener onmessage per ricevere messaggi dall'altro contesto:

const messageChannel = new MessageChannel();

//Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

//Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

Il service worker riceve la porta, ne salva un riferimento e lo utilizza per inviare un messaggio all'altro lato:

let communicationPort;

//Save reference to port
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

//Send messages
communicationPort.postMessage({type: 'MSG_ID'});

MessageChannel è attualmente supportato da tutti i principali browser.

API avanzate: sincronizzazione in background e recupero in background

In questa guida abbiamo esplorato i modi per implementare tecniche di comunicazione bidirezionale per casi relativamente semplici, come il passaggio di un messaggio di stringa che descrive l'operazione da eseguire o un elenco di URL da memorizzare nella cache da un contesto all'altro. In questa sezione esploreremo due API per gestire scenari specifici: mancanza di connettività e download lunghi.

Sincronizzazione in background

Browser Support

• 49
• 79
• x
• x

Source

Un'app di chat potrebbe voler assicurarsi che i messaggi non vengano mai persi a causa di una connettività scadente. L'API Background Sync ti consente di posticipare le azioni da riprovare quando l'utente ha una connettività stabile. Questo è utile per garantire che tutto ciò che l'utente vuole inviare venga effettivamente inviato.

Anziché l'interfaccia postMessage(), la pagina registra un sync:

navigator.serviceWorker.ready.then(function (swRegistration) {
  return swRegistration.sync.register('myFirstSync');
});

Il service worker rimane in ascolto dell'evento sync per elaborare il messaggio:

self.addEventListener('sync', function (event) {
  if (event.tag == 'myFirstSync') {
    event.waitUntil(doSomeStuff());
  }
});

La funzione doSomeStuff() deve restituire una promessa che indica l'esito positivo o negativo di ciò che sta tentando di fare. Se la promessa viene soddisfatta, la sincronizzazione è completata. Se l'operazione non va a buon fine, verrà pianificata un'altra sincronizzazione per riprovare. I nuovi tentativi di sincronizzazione attendono anche la connettività e utilizzano un backoff esponenziale.

Una volta eseguita l'operazione, il service worker può comunicare con la pagina per aggiornare l'interfaccia utente utilizzando una delle API di comunicazione esplorate in precedenza.

La Ricerca Google utilizza la sincronizzazione in background per rendere persistenti le query non riuscite a causa di una connettività scadente e riprovarle in un secondo momento quando l'utente è online. Una volta eseguita l'operazione, comunicano il risultato all'utente tramite una notifica push web:

Nota: consulta Esperienze di ricerca resilienti per scoprire come implementare questa funzionalità utilizzando Workbox Background Sync.

Recupero dello sfondo

Browser Support

• 74
• 79
• x
• x

Source

Per attività relativamente brevi, come l'invio di un messaggio o di un elenco di URL da memorizzare nella cache, le opzioni esplorate finora sono una buona scelta. Se l'attività richiede troppo tempo, il browser interromperà il service worker, altrimenti la privacy e la batteria dell'utente saranno a rischio.

L'API Background Fetch ti consente di trasferire un'attività lunga a un service worker, ad esempio il download di film, podcast o livelli di un gioco.

Per comunicare con il service worker dalla pagina, utilizza backgroundFetch.fetch anziché postMessage():

navigator.serviceWorker.ready.then(async (swReg) => {
  const bgFetch = await swReg.backgroundFetch.fetch(
    'my-fetch',
    ['/ep-5.mp3', 'ep-5-artwork.jpg'],
    {
      title: 'Episode 5: Interesting things.',
      icons: [
        {
          sizes: '300x300',
          src: '/ep-5-icon.png',
          type: 'image/png',
        },
      ],
      downloadTotal: 60 * 1024 * 1024,
    },
  );
});

L'oggetto BackgroundFetchRegistration consente alla pagina di ascoltare l'evento progress per seguire l'avanzamento del download:

bgFetch.addEventListener('progress', () => {
  // If we didn't provide a total, we can't provide a %.
  if (!bgFetch.downloadTotal) return;

  const percent = Math.round(
    (bgFetch.downloaded / bgFetch.downloadTotal) * 100,
  );
  console.log(`Download progress: ${percent}%`);
});

La UI viene aggiornata per indicare l'avanzamento di un download (a sinistra). Grazie ai service worker, l'operazione può continuare a essere eseguita anche quando tutte le schede sono state chiuse (a destra).

Nota: consulta la guida al recupero in background.

Passaggi successivi

In questa guida abbiamo esplorato il caso più generale di comunicazione tra pagina e service worker (comunicazione bidirezionale).

Molte volte, un contesto potrebbe dover comunicare con l'altro, senza ricevere una risposta. Consulta le seguenti guide per informazioni su come implementare tecniche unidirezionali nelle tue pagine da e verso il service worker, insieme a casi d'uso ed esempi di produzione:

• Guida alla memorizzazione nella cache imperativa: chiamata di un service worker dalla pagina per memorizzare nella cache le risorse in anticipo (ad es. in scenari di precaricamento).
• Trasmettere aggiornamenti: chiamare la pagina dal service worker per informare su aggiornamenti importanti (ad es. è disponibile una nuova versione dell'app web).