https://developers.google.com/web/fundamentals/primers/service-workers?hl=es
Están llegando a la Web ricas experiencias sin conexión, sincronizaciones periódicas en segundo plano, notificaciones push: funcionalidad que normalmente requiere una aplicación nativa. Los service workers brindan la base técnica que hace posibles todas estas funciones.
Qué es un service worker
Un service worker es una secuencia de comandos que tu navegador ejecuta en segundo plano, separado de una página web, abriéndoles la puerta a funciones que no necesitan una página web ni interacción de usuario. En la actualidad, ya incorporan funciones como notificaciones push y sincronización en segundo plano. En el futuro, los service workers podrían admitir funciones como sincronización periódica o geovallado. La función principal que analizamos en este instructivo es la capacidad de interceptar y manejar solicitudes de red, incluida la administración programática de una caché de respuestas.
El motivo por el que esta es una API tan emocionante es que te permite admitir experiencias sin conexión, brindándoles a los programadores control total sobre la experiencia.
Antes del service worker, existía otra API que brindaba a los usuarios una experiencia sin conexión en la Web, llamada AppCache. Hay una serie de problemas de la API de AppCache que se pueden evitar con los service workers.
Algunas consideraciones sobre los service workers:
Son JavaScript Workers, así que no pueden acceder al DOM directamente. Como alternativa, un service worker puede comunicarse con las páginas que controla porque responde a mensajes enviados a través de la interfaz de postMessage; estas páginas pueden manipular el DOM si es necesario.
Un service worker es un proxy de red programable. Esto te permite controlar la manera en que se procesan las solicitudes de red de tu página.
Se detiene cuando no está en uso y se reinicia cuando se lo necesita nuevamente, así que no puedes confiar en el estado global de los controladores onfetch y onmessage de un service worker. Si hay información que necesitas que persista para reutilizar entre reinicios, los service workers tienen acceso a la API de IndexedDB.
Los service workers hacen gran uso de las promesas, así que, si no estás familiarizado con el concepto, deberías dejar de leer esto y leer Promesas de JavaScript: introducción.
El ciclo de vida del service worker
Un service worker tiene un ciclo de vida completamente separado de tu página web.
Si quieres instalar un service worker para tu sitio, debes registrarlo. Esto se realiza en el lenguaje JavaScript de tu página. Cuando registres un service worker, el navegador iniciará la etapa de instalación del proceso en segundo plano.
Por lo general, durante la etapa de instalación, te convendrá almacenar en caché algunos elementos estáticos. Si todos los archivos se almacenan correctamente en caché, se instalará el service worker. Si no se puede descargar o almacenar en caché alguno de los archivos, el paso de instalación fallará y el service worker no se activará (es decir, no se instalará). Si esto ocurre, no te preocupes; se realizará un nuevo intento la próxima vez. Sin embargo, si la instalación tiene éxito, podrás estar seguro de que dichos elementos estáticos estarán en la caché.
Después de la instalación, comenzará el paso de activación. Es una excelente oportunidad para administrar las cachés anteriores. Trataremos este asunto durante la sección sobre la actualización de los service workers.
Después de la etapa de activación, el service worker controlará todas las páginas que estén a su alcance. Sin embargo, no se controlará la página que registró por primera vez el service worker hasta que se vuelva a cargar. Una vez que un service worker tiene el control, estará en uno de dos estados: el service worker se rescindirá para ahorrar memoria o controlará eventos de mensaje y extracción que ocurran cuando se emita un mensaje o solicitud de red desde tu página.
A continuación, se muestra una versión muy simplificada del ciclo de vida del service worker cuando se instala por primera vez.
ciclo de vida de un service worker
Requisitos previos
Compatibilidad con navegadores
Cada vez hay más opciones de navegadores. Los service workers son compatibles con Chrome, Firefox y Opera. Microsoft Edge está mostrando apoyo públicamente. Incluso Safari ha demostrado interés en desarrollos futuros. Puedes seguir el progreso de todos los navegadores en el sitio is Serviceworker ready? de Jake Archibald.
Se necesita HTTPS
Durante el desarrollo, podrás usar el service worker por medio de localhost, pero para implementarlo en un sitio deberás configurar HTTPS en tu servidor.
Con los service workers puedes tomar el control de una conexión, y crear y filtrar respuestas. Herramientas poderosas. Si bien es muy probable que uses este poder con buenos propósitos, es posible que un intermediario no lo haga. Para evitar esto, solo puedes registrar service workers en páginas que se proporcionen a través de HTTPS. De esta forma, nos aseguramos de que el service worker que recibe el navegador no se ha manipulado durante su recorrido por la red.
Las páginas de GitHub se brindan a través de HTTPS, así que son un excelente lugar para alojar demostraciones.
Si deseas agregar HTTPS a tu servidor, deberás conseguir un certificado TLS y configurarlo para el servidor. Esto varía según tu configuración; consulta la documentación de tu servidor y no olvides visitar el generador de configuraciones SSL de Mozilla para conocer las prácticas recomendadas.
Registro de un service worker
Para instalar un service worker, debes registrarlo en tu página para iniciar el proceso. De esta forma, se comunica al navegador dónde reside el archivo JavaScript de tu service worker.
if (‘serviceWorker’ in navigator) {
window.addEventListener(‘load’, function() {
navigator.serviceWorker.register(’/sw.js’).then(function(registration) {
// Registration was successful
console.log('ServiceWorker registration successful with scope: ', registration.scope);
}, function(err) {
// registration failed 😦
console.log('ServiceWorker registration failed: ', err);
});
});
}
Este código verifica si la API del service worker está disponible. Si está disponible, se registra el service worker de /sw.js una vez que se carga la página.
Puedes llamar a register() sin ningún problema cada vez que se cargue una página. El navegador determinará si el service worker está registrado o no, y actuará según corresponda.
Un detalle que hay que tener en cuenta del método register() es la ubicación del archivo del proceso de trabajo de servicio. En este caso, observarás que el archivo del service worker se encuentra en la raíz del dominio. Esto significa que el alcance de este proceso será el origen completo. En otras palabras, el service worker recibirá eventos fetch para todos los elementos de este dominio. Si registramos el archivo del service worker en /example/sw.js, el service worker solo identificaría eventos fetch de páginas cuyas URL comiencen con /example/ (es decir, /example/page1/, /example/page2/).
Para ver si un service worker está habilitado, ahora puedes ir a chrome://inspect/#service-workers y buscar tu sitio.
