Comunicación bidireccional con los service workers

En algunos casos, es posible que una app web necesite establecer un canal de comunicación doblez entre la página y el service worker.

Por ejemplo, en una AWP de podcast, se podría compilar una función que permita al usuario descargar episodios para consumo sin conexión y permitir que el service worker mantenga la página informada con regularidad sobre el progreso, de modo que el subproceso principal pueda actualizar la IU.

En esta guía, exploraremos las diferentes maneras de implementar una comunicación doblez entre el contexto de Window y service worker. Para ello, exploraremos diferentes APIs, la biblioteca de Workbox y algunos casos avanzados.

Usa Workbox

workbox-window es un conjunto de módulos de la biblioteca de Workbox que están destinados a ejecutarse en el contexto de la ventana. La clase Workbox proporciona un método messageSW() para enviar un mensaje al service worker registrado de la instancia y esperar una respuesta.

El siguiente código de la página crea una instancia nueva de Workbox y envía un mensaje al service worker para obtener su versión:

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

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

El service worker implementa un objeto de escucha de mensajes en el otro extremo y responde al service worker registrado:

const SW_VERSION = '1.0.0';

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

De forma interna, la biblioteca usa una API de navegador que revisaremos en la siguiente sección: Message Channel, pero abstrae muchos detalles de la implementación, lo que facilita su uso y aprovecha la compatibilidad con todo el navegador que tiene esta API.

Uso de las APIs del navegador

Si la biblioteca de Workbox no es suficiente para tus necesidades, hay varias APIs de nivel inferior disponibles para implementar la comunicación "doblez" entre las páginas y los service worker. Tienen algunas similitudes y diferencias:

Similitudes:

• En todos los casos, la comunicación comienza en un extremo a través de la interfaz postMessage() y se recibe en el otro mediante la implementación de un controlador message.
• En la práctica, todas las APIs disponibles nos permiten implementar los mismos casos de uso, pero algunas de ellas podrían simplificar el desarrollo en algunas situaciones.

Diferencias:

• Tienen diferentes maneras de identificar el otro lado de la comunicación: algunas usan una referencia explícita al otro contexto, mientras que otras pueden comunicarse implícitamente a través de un objeto proxy con una instancia en cada lado.
• La compatibilidad con navegadores varía entre ellos.

API de Broadcast Channel

La API de Broadcast Channel permite una comunicación básica entre contextos de navegación a través de objetos BroadcastChannel.

Para implementarlo, primero, cada contexto debe crear una instancia de un objeto BroadcastChannel con el mismo ID y enviar y recibir mensajes desde él:

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

El objeto BroadcastChannel expone una interfaz postMessage() para enviar un mensaje a cualquier contexto de escucha:

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

Cualquier contexto de navegador puede escuchar mensajes a través del método onmessage del objeto BroadcastChannel:

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

Como se ve, no hay referencia explícita a un contexto particular, por lo que no es necesario obtener primero una referencia al service worker o a un cliente en particular.

La desventaja es que, en el momento en que se redacta este documento, la API es compatible con Chrome, Firefox y Edge, pero otros navegadores, como Safari, aún no la admiten.

API del cliente

La API de cliente te permite obtener una referencia a todos los objetos WindowClient que representan las pestañas activas que controla el service worker.

Dado que la página está controlada por un solo service worker, escucha y envía mensajes al service worker activo directamente a través de la interfaz 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
  }
};

De manera similar, el service worker escucha los mensajes implementando un objeto de escucha onmessage:

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

Para comunicarse con cualquiera de sus clientes, el service worker obtiene un array de objetos WindowClient mediante la ejecución de métodos como Clients.matchAll() y Clients.get(). Luego, puede postMessage() cualquiera de ellos:

//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 es una buena opción para comunicarse fácilmente con todas las pestañas activas de un service worker de una manera relativamente directa. Todos los navegadores principales admiten la API, pero es posible que no todos sus métodos estén disponibles, así que asegúrate de verificar la compatibilidad del navegador antes de implementarla en tu sitio.

Canal de mensajes

Message Channel requiere definir y pasar un puerto de un contexto a otro para establecer un canal de comunicación bidireccional.

Para inicializar el canal, la página crea una instancia de un objeto MessageChannel y lo usa para enviar un puerto al service worker registrado. La página también implementa un objeto de escucha onmessage para recibir mensajes del otro contexto:

const messageChannel = new MessageChannel();

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

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

El service worker recibe el puerto, guarda una referencia a él y lo usa para enviar un mensaje al otro lado:

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'});

Actualmente, MessageChannel es compatible con todos los navegadores principales.

APIs avanzadas: sincronización en segundo plano y recuperación en segundo plano

En esta guía, exploramos formas de implementar técnicas de comunicación dos vías para casos relativamente simples, como pasar un mensaje de cadena que describa la operación que se realizará o una lista de URLs para almacenar en caché de un contexto a otro. En esta sección, exploraremos dos APIs para manejar situaciones específicas: falta de conectividad y descargas largas.

Sincronización en segundo plano

Una app de chat podría querer asegurarse de que los mensajes nunca se pierdan debido a problemas de conectividad. La API de sincronización en segundo plano te permite diferir las acciones que se deben reintentar cuando el usuario tiene una conectividad estable. Esto es útil para garantizar que lo que el usuario desea enviar se envíe realmente.

En lugar de la interfaz postMessage(), la página registra un sync:

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

Luego, el service worker detecta el evento sync para procesar el mensaje:

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

La función doSomeStuff() debe mostrar una promesa que indique el éxito o el fracaso de lo que se esté tratando de hacer. Si se completa, la sincronización se completó. Si falla, se programará otra sincronización para reintentarlo. Las sincronizaciones de reintento también esperan la conectividad y emplean una retirada exponencial.

Una vez realizada la operación, el service worker puede comunicarse con la página para actualizar la IU mediante cualquiera de las APIs de comunicación que se exploraron anteriormente.

La Búsqueda de Google usa la sincronización en segundo plano para conservar las consultas fallidas debido a mala conectividad y volver a intentarlo más tarde cuando el usuario está en línea. Una vez realizada la operación, comunican el resultado al usuario a través de una notificación push web:

Recuperación en segundo plano

Las opciones exploradas hasta ahora son una buena opción para trabajos relativamente breves, como enviar un mensaje o una lista de URLs para almacenar en caché. Si la tarea lleva demasiado tiempo, el navegador cerrará el service worker; de lo contrario, supone un riesgo para la privacidad y la batería del usuario.

La API de recuperación en segundo plano te permite descargar una tarea larga en un service worker, como descargar películas, podcasts o niveles de un juego.

Para comunicarte con el service worker desde la página, usa backgroundFetch.fetch, en lugar de 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,
    },
  );
});

El objeto BackgroundFetchRegistration permite que la página escuche el evento progress para seguir el progreso de la descarga:

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}%`);
});

Próximos pasos

En esta guía, exploramos el caso más general de la comunicación entre la página y los service workers (comunicación bidireccional).

Muchas veces, es posible que uno necesite solo un contexto para comunicarse con el otro, sin recibir una respuesta. Consulta las siguientes guías para obtener orientación sobre cómo implementar técnicas unidireccionales en tus páginas desde y hacia el service worker, junto con casos de uso y ejemplos de producción:

• Guía de almacenamiento en caché imperativo: Llamar a un service worker desde la página a los recursos en caché por adelantado (p.ej., en situaciones de carga previa).
• Transmisión de actualizaciones: Llamar a la página desde el service worker para informar sobre actualizaciones importantes (p.ej., hay una nueva versión de webapp disponible).