Service workers

Los usuarios esperan que las apps se inicien con conexiones de red lentas o débiles, o incluso sin conexión. Esperan que el contenido con el que interactuaron más recientemente, como itinerarios o pistas de medios de comunicación, esté disponible y se pueda usar. Cuando no es posible hacer una solicitud, esperan que la app se lo diga en lugar de fallar de manera silenciosa. Y los usuarios quieren hacerlo todo rápidamente. Como podemos ver en este estudio, los milisegundos generan millones, incluso una mejora de 0.1 segundo en los tiempos de carga puede aumentar la conversión en hasta un 10%. En resumen, los usuarios esperan que las AWP sean confiables y, por eso, contamos con service worker.

Service Workers de Hello

Un service worker como proxy de middleware, que se ejecuta en el dispositivo, entre la AWP y los servidores, que incluye tus propios servidores y los servidores multidominio

Cuando una app solicita un recurso cubierto por el alcance del service worker, incluso cuando un usuario está sin conexión, el service worker intercepta la solicitud y actúa como un proxy de red. Luego, puede decidir si debería entregar el recurso desde la caché a través de la API de Cache Storage, desde la red como normalmente sucedería sin un service worker, o crearlo a partir de un algoritmo local. Esto te permite proporcionar una experiencia similar a la de una app de plataforma. Incluso puede funcionar completamente sin conexión.

Cómo registrar un service worker

Antes de que un service worker tome el control de tu página, debes registrarla para tu AWP. Esto significa que la primera vez que un usuario acceda a tu AWP, las solicitudes de red irán directamente a tu servidor porque el service worker aún no controla tus páginas.

Después de verificar si el navegador es compatible con la API de Service Worker, tu AWP podrá registrar un service worker. Cuando se carga, el service worker configura la tienda entre tu AWP y la red, intercepta solicitudes y entrega las respuestas correspondientes.

if ('serviceWorker' in navigator) {
   navigator.serviceWorker.register("/serviceworker.js");
}

Verifica si un service worker está registrado

Para verificar si un service worker está registrado, usa las herramientas para desarrolladores de tu navegador favorito.

En navegadores con Firefox y Chromium (Microsoft Edge, Google Chrome o Samsung Internet), haz lo siguiente:

  1. Abre las herramientas para desarrolladores y, luego, haz clic en la pestaña Aplicación.
  2. En el panel izquierdo, selecciona Service Workers.
  3. Comprueba que la URL de la secuencia de comandos del service worker aparezca con el estado "Activada". Aprenderás qué significa este estado en la sección Ciclo de vida de este capítulo. En Firefox, el estado puede ser "En ejecución" o "Detenido".

En Safari:

  1. Haz clic en el menú Develop y, a continuación, en el submenú Service Workers.
  2. Comprueba que aparezca una entrada con el origen actual en el submenú. Abre un inspector en el contexto del service worker.
Herramientas para desarrolladores de service worker en Chrome, Firefox y Safari.
Herramientas para desarrolladores de service worker en Chrome, Firefox y Safari.

Permiso

La carpeta en la que se encuentra tu service worker determina su alcance. Un service worker que se encuentre en example.com/my-pwa/sw.js puede controlar cualquier navegación en la ruta de acceso my-pwa o versiones anteriores, como example.com/my-pwa/demos/. Los service workers solo pueden controlar los elementos (páginas, trabajadores, colectivamente "clientes") que estén en su alcance. El alcance se aplica a las pestañas del navegador y a las ventanas de AWP.

Solo se permite un service worker por alcance. Cuando está activa y en ejecución, solo hay una instancia disponible, sin importar cuántos clientes haya en la memoria (como ventanas de AWP o pestañas del navegador).

Safari tiene una administración de alcance más compleja, conocida como particiones, que afecta el funcionamiento de los permisos si tienes iframes multidominio. Para obtener más información sobre la implementación de WebKit, lee su entrada de blog.

Ciclo de vida

Los service workers tienen un ciclo de vida que determina la forma en que se instalan, es decir, independiente de la instalación de la AWP. El ciclo de vida del service worker comienza con el registro del service worker. Luego, el navegador intenta descargar y analizar el archivo del service worker. Si el análisis se realiza correctamente, se activa su evento install. El evento install solo se activa una vez.

La instalación del service worker se realiza de forma silenciosa, sin solicitar el permiso del usuario, incluso si este no instala la AWP. La API de Service Worker incluso está disponible en plataformas que no admiten la instalación de AWP, como Safari y Firefox en dispositivos de escritorio.

Después de la instalación, el service worker aún no tiene el control de sus clientes, incluida tu AWP. Primero se debe activar. Cuando el service worker esté listo para controlar a sus clientes, se activará el evento activate. Sin embargo, esto no significa que se administrará la página que registró el service worker. De forma predeterminada, el service worker no tomará el control hasta la próxima vez que navegues a esa página, ya sea porque la vuelvas a cargar o porque volverás a abrir la AWP.

Puedes escuchar eventos en el alcance global del service worker con el objeto self.

serviceworker.js

// This code executes in its own worker or thread
self.addEventListener("install", event => {
   console.log("Service worker installed");
});
self.addEventListener("activate", event => {
   console.log("Service worker activated");
});

Cómo actualizar un service worker

Los service worker se actualizan cuando el navegador detecta que el service worker que actualmente controla el cliente y que la versión nueva (desde tu servidor) del mismo archivo presentan una diferencia de bytes.

Después de una instalación exitosa, el nuevo service worker esperará a activarse hasta que el service worker existente (anterior) ya no controle a ningún cliente. Este estado se denomina "esperando" y es la forma en que el navegador garantiza que solo se ejecute una versión de tu service worker a la vez. Actualizar una página o volver a abrir la AWP no hará que el nuevo service worker tome el control. El usuario debe cerrar o salir de todas las pestañas y ventanas con el service worker actual y luego volver a la página anterior. Solo entonces el nuevo service worker tomará el control. Visita este artículo sobre el ciclo de vida del service worker para obtener más información.

Vida útil de service worker

Una vez instalado y registrado, un service worker puede administrar todas las solicitudes de red dentro de su alcance. Se ejecuta en su propio subproceso, y el navegador controla la activación y la cancelación. Esto permite que funcione incluso antes o después de que se abra la AWP. Si bien los service workers se ejecutan en su propio subproceso, no hay garantía de que el estado en la memoria persista entre ejecuciones de un service worker, así que asegúrate de que todo lo que desees reutilizar en cada ejecución esté disponible en IndexedDB o en algún otro almacenamiento persistente.

Si aún no se está ejecutando, se iniciará un service worker cada vez que se solicite una solicitud de red en su alcance o cuando se reciba un evento de activación, como una sincronización periódica en segundo plano o un mensaje push.

Los service worker no funcionan de forma indefinida. Si bien los tiempos exactos difieren entre navegadores, los service worker se cierran si están inactivos durante unos segundos o si han estado ocupados durante demasiado tiempo. Si se cerró un service worker y se produce un evento que podría iniciarlo, este se reiniciará.

Capacidades

Con un service worker registrado y activo, tienes un subproceso con un ciclo de vida de ejecución completamente diferente al principal de tu AWP. Sin embargo, de forma predeterminada, el archivo del service worker no tiene ningún comportamiento. No almacenará en caché ni entregará ningún recurso, ya que esto lo debe hacer tu código. Descubrirás cómo hacerlo en los siguientes capítulos.

Las capacidades de los procesos de trabajo de servicio no son solo para enviar solicitudes HTTP o usar servidores proxy; hay otras funciones disponibles además de otras para otros fines, como la ejecución de código en segundo plano, las notificaciones push web y el procesamiento de pagos. Analizaremos estas incorporaciones en el capítulo de funciones.

Recursos