Comunicación bidireccional con los service workers

Andrew Guan

Demián Renzulli

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

Por ejemplo, en una PWA de podcast, se podría compilar una función para permitir que el usuario descargue episodios para consumirlos 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 formas de implementar una comunicación bidireccional entre el contexto de Window y el service worker, a través de diferentes APIs, la biblioteca de Workbox y algunos casos avanzados.

Nota: Consulta la descripción general de los trabajadores para obtener una explicación general de cuándo usar trabajadores web en lugar de trabajadores de servicio y el resto de la serie Comunicación con trabajadores para obtener guías sobre otros casos de uso comunes.

Usa Workbox

workbox-window es un conjunto de módulos de la biblioteca de Workbox que están diseñados para 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 página crea una nueva instancia 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 del navegador que revisaremos en la siguiente sección: Canal de mensajes, pero abstrae muchos detalles de implementación, lo que facilita su uso, a la vez que aprovecha la amplia compatibilidad con navegadores que tiene esta API.

Usa 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 "bidireccional" entre las páginas y los service workers. 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 extremo 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 formas de identificar el otro lado de la comunicación: algunos usan una referencia explícita al otro contexto, mientras que otros pueden comunicarse de forma implícita a través de un objeto proxy con instancias en cada lado.
• La compatibilidad con los navegadores varía entre ellos.

API de Broadcast Channel

Browser Support

• 54
• 79
• 38
• 15.4

Source

La API de Broadcast Channel permite la 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 del 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 puede ver, no hay una referencia explícita a un contexto en particular, por lo que no es necesario obtener primero una referencia al service worker ni a ningún cliente en particular.

La desventaja es que, en el momento de escribir este artículo, la API es compatible con Chrome, Firefox y Edge, pero otros navegadores, como Safari, aún no la admiten.

API del cliente

Browser Support

• 40
• 17
• 44
• 11.1

Source

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.

Como 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
  }
};

Del mismo modo, 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 ejecutando 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 con facilidad con todas las pestañas activas de un service worker de una manera relativamente sencilla. La API es compatible con todos los navegadores principales, 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.

Nota: En esta guía, nos enfocamos principalmente en los casos de uso de confiabilidad. Otro uso interesante de esta API es sincronizar datos entre documentos a través de un service worker. Consulta este episodio de HTTP 203 para obtener más información.

Canal de mensajes

Browser Support

• 2
• 12
• 41
• 5

Source

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 bidireccional para casos relativamente simples, como pasar un mensaje de cadena que describa la operación que se debe realizar o una lista de URLs para almacenar en caché de un contexto al otro. En esta sección, exploraremos dos APIs para controlar situaciones específicas: falta de conectividad y descargas largas.

Sincronización en segundo plano

Browser Support

• 49
• 79
• x
• x

Source

Es posible que una app de chat quiera asegurarse de que los mensajes nunca se pierdan debido a una mala conectividad. La API de Background Sync te permite aplazar las acciones que se volverán a intentar cuando el usuario tenga una conectividad estable. Esto es útil para garantizar que se envíe lo que el usuario quiere enviar.

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 escucha el evento sync para procesar el mensaje:

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

La función doSomeStuff() debería mostrar una promesa que indique el éxito o el fracaso de lo que intenta hacer. Si se cumple, la sincronización se completa. Si falla, se programará otra sincronización para volver a intentarlo. Los reintentos de sincronización también esperan a que haya conectividad y emplean una retirada exponencial.

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

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

Nota: Consulta Experiencias de búsqueda resilientes para aprender a implementar esta función con la sincronización en segundo plano de Workbox.

Recuperación en segundo plano

Browser Support

• 74
• 79
• x
• x

Source

Para tareas relativamente cortas, como enviar un mensaje o una lista de URLs para almacenar en caché, las opciones que se exploraron hasta ahora son una buena opción. Si la tarea tarda demasiado, el navegador cerrará el service worker; de lo contrario, se pondrá en riesgo la privacidad y la batería del usuario.

La API de Background Fetch te permite descargar una tarea larga a 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}%`);
});

La IU se actualiza para indicar el progreso de una descarga (izquierda). Gracias a los service workers, la operación puede seguir ejecutándose cuando se cierran todas las pestañas (derecha).

Nota: Consulta la guía de recuperación en segundo plano.

Próximos pasos

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

Muchas veces, es posible que solo se necesite 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: Llama a un service worker desde la página para almacenar en caché los recursos con anticipación (p.ej., en situaciones de carga previa).
• Transmitir actualizaciones: Llamar a la página desde el service worker para informar sobre actualizaciones importantes (p.ej., hay una nueva versión de la app web disponible).