Service Worker API

must be provided

Los Service workers actúan esencialmente como proxy servers asentados entre las aplicaciones web, el navegador y la red (cuando está accesible). Están destinados, entre otras cosas, a permitir la creación de experiencias offline efectivas, interceptando peticiones de red y realizando la acción apropiada si la conexión de red está disponible y hay disponibles contenidos actualizados en el servidor. También permitirán el acceso a notificaciones tipo push y APIs de sincronización en segundo plano.

Conceptos y uso de Service worker

Un service worker es unworker manejado por eventos registrado para una fuente y una ruta. Consiste en un fichero JavaScript que controla la página web (o el sitio) con el que está asociado, interceptando y modificando la navegación y las peticiones de recursos, y cacheando los recursos de manera muy granular para ofrecer un control completo sobre cómo la aplicación debe comportarse en ciertas situaciones (la mas obvia es cuando la red no está disponible).

Un service worker se ejecuta en un contexto worker: por lo tanto no tiene acceso al DOM, y se ejecuta en un hilo distinto al JavaScript principal de la aplicación, de manera que no es bloqueante. Está diseñado para ser completamente asíncrono, por lo que APIs como elXHR asíncrono ylocalStorage no se pueden usar dentro de un service worker.

Los service workers solo funcionan sobre HTTPS, por razones de seguridad. Modificar las peticiones de red en abierto permitiría ataques man in the middle realmente peligrosos. En Firefox, las APIs de service worker se ocultan y no pueden ser empleadas cuando el usuario está enmodo de navegación en privado.

Nota:Los Service Workers mejoran los intentos anteriores en este área tal comoAppCache puesto que no hacen suposiciones sobre qué se está intentando hacer para luego tener que cortar cuando las suposiciones no son correctas; hay control granular sobre todos los aspectos.

Nota:Los Service workers hace un uso intensivo de laspromesas, por lo que generalmente esperarán a que lleguen las respuestasas correspondientes, tras lo cual responderán con una acción de éxito o de fracaso. La arquitectura de promesas es ideal en este caso.

Registro

Un service worker se registra primero mediante el métodoServiceWorkerContainer.register(). Si ha habido éxito, el service worker se descargará al cliente e intentará la instalación/activación (ver más abajo) de las URLs accedidas por el usuario dentro de todo su origen de datos, o dentro de algún subconjunto especificado por el autor.

Descarga, instalación y activación

En este punto, su service worker observará el siguiente ciclo de vida:

Descarga
Instalación
Activación

El service worker se descaga inmediatamente cuando un usuario accede por primera vez a un sitio controlado por el mismo.

Después de esto se descarga cada 24 horas aproximadamente. Se puede descargar con más frecuencia, perodebe ser descargado cada 24 horas para prevenir que una mala programación sea molesta durante mucho tiempo.

La instalación se realiza cuando el fichero descargado es nuevo, es decir, diferente a otro service worker existente (comparado byte a byte), o si es el primero descargado para esta página/sitio.

Si es la primera vez que el service worker está disponible se intenta la instalación, y tras una instalación satisfactoria se activa.

Si ya existe un service worker disponible la nueva versión se instala en segundo plano, pero no se activa -en ese momento se llamaworker in waiting. Sólo se activa cuando ya no hay más páginas cargadas que utilicen el antiguo service worker. En cuanto no hay más páginas de este estilo cargadas, el nuevo service worker se activa (pasando a ser elactive worker). La activación se puede realizar antes medianteServiceWorkerGlobalScope.skipWaiting() y las páginas existentes se pueden llamar por el active worker usandoClients.claim().

Presta atención aInstallEvent; es habitual preparar tu service worker para usarlo cuando se dispara, por ejemplo creando una caché que utilice la API incorporada de almacenamiento, y colocando los contenidos dentro de ella para poder usarlos con la aplicación offline.

También hay un eventoactivate. El momento en el que este evento se activa es, en general, un bueno momento para limpiar viejas cachés y demás cosas asociadas con la versión previa de tu service worker.

Tu service worker puede responder a las peticiones usando el eventoFetchEvent. Puedes modificar la respuesta a estas peticiones de la manera que quieras, usando el métodoFetchEvent.respondWith.

Nota:Dado queoninstall/onactivate puede tardar un poco en completarse, la especificación de service worker spec provee un métodowaitUntil que, cuando es llamadooninstall oonactivate, pasa una promesa. Los eventos funcionales no se envían al service worker hasta que la promesa se resuelve con éxito.

Para un tutorial completo que muestra cómo construir tu primer ejemplo básico, leeUsing Service Workers.

Otras posibilidades

Los service workers también pueden usarse para cosas como:

Sincronización de datos en background
Responder a peticiones de recursos desde otros orígenes
Recibir actualizaciones centralizadas de datos costosos de calcular tales como geolocalización o giroscopio, de manera que muchas páginas puedan hacer uso de un mismo conjunto de datos
Compilación Client-side y gestión de dependencias de CoffeeScript, less, CJS/AMD modules, etc. para desarrollo
Enlace para servicios en background
Plantillas personalizadas basadas en ciertos patrones URL
Mejoras de rendimiento, por ejemplo pre-fetching de recursos que es probable que el usuario requiera en un futuro próximo, como las próximas imágenes de un album de fotos.

En el futuro, los service workers podrán hacer una cantidad de cosas útiles para la plataforma web que estarán muy próximos a las aplicaciones nativas. Interesantement, otras especificacions pueden comenzar y lo harán a hacer uso del contexto de service worker, por ejemplo:

Sincronización en background: Pone en marcha un service worker aunque el usuario no esté en el sitio de manera que las cachés se puedan actualizar, etc.
Reacción a mensajes tipo push: Pone en marcha un service worker para enviar a los usuarios un mensaje para notificarles de que hay disponible nuevos contenidos.
Reacción ante una fecha y hora determinados.
Creación de geo-fronteras

Interfaces

Cache: Representa el almacenamiento para un par de objetosRequest /Response que son cacheados como parte del ciclo de vida deServiceWorker.
CacheStorage: Representa el almacenamiento de objetosCache. Proporciona un directorio maestro de todos los nombres de caché a los que puede acceder unServiceWorker y mantiene un mapa de nombres (strings) correspondientes a objetosCache.
Client: Representa el ámbito de un cliente service worker. Un cliente service worker es bien un documento en un contexto de navador, bien unSharedWorker, que está controlado por un worker activo.
Clients: Representa un contenedor para una lista de objetosClient; principal vía de acceso de los clientes service worker al origen actual.
ExtendableEvent: Extiende el tiempo de vida de los eventosinstall yactivate lanzados enServiceWorkerGlobalScope como parte del ciclo de vida del service worker. Esto asegura que cualquier evento funcional (comoFetchEvent) no se despachan alServiceWorker hasta que actualiza los esquemas de base de datos, borra entradas de caché antiguas, etc.
ExtendableMessageEvent: Es el objeto evento de unmessage lanzado en un service worker (cuando se recibe un mensaje en elServiceWorkerGlobalScope desde otro contexto) — extiende el tiempo de vida de tales eventos.
FetchEvent: Parametro pasado en el controladorServiceWorkerGlobalScope.onfetch,FetchEvent representa una acción de consulta (fetch) despachada en elServiceWorkerGlobalScope de unServiceWorker. Contiene información sobre la petición y respuesta resultante, y proporciona el métodoFetchEvent.respondWith(), que nos permite proporcionar una respuesta arbitraria a la página controlada.
InstallEvent: Parámetro pasado en el controladoroninstall, el interfazInstallEvent representa una acctión de instalación realizada en elServiceWorkerGlobalScope de unServiceWorker. Como hijo deExtendableEvent, asegura que los eventos funcionales comoFetchEvent no se llevan a cabo durante la instalación.
Navigator.serviceWorker: Devuelve un objetoServiceWorkerContainer, que proporciona acceso al registro, eliminación, actualización y comunicación con los objetosServiceWorker para eldocumento asociado.
NotificationEvent: Parámetro pasado en el controladoronnotificationclick, el interfazNotificationEvent representa una notificación del evento click ejecutado enServiceWorkerGlobalScope de unServiceWorker.
ServiceWorker: Representa un service worker. Multiples contextos de navegación (e.g. pages, workers, etc.) se pueden asociar con el mismo objetoServiceWorker.
ServiceWorkerContainer: Proporciona un objeto que representa el service worker como una unidad en el ecosistema de red, incluyendo servicios para registrar, eliminar y actualizar los service workers, y acceder al estado de los service workers y sus registros.
ServiceWorkerGlobalScope: Representa el contexto global de ejecución de un service worker.
ServiceWorkerMessageEventObsoleto: Representa un mensaje envaido a un ServiceWorkerGlobalScope. Observese que este interfaz está considerado obsoleto en navegadores modernos. Los mensajes de service worker no podrán utilizar el interfazMessageEvent, por consistencia con otras características de mensajería web.
ServiceWorkerRegistration: Representa un registro service worker.
SyncEventNo estándar: El interfaz SyncEvent representa una acción sync ejecutada en el ServiceWorkerGlobalScope de un ServiceWorker.
SyncManagerNo estándar: Proporciona un interfaz para registrar y listar registros sync.
WindowClient: Representa el ámbito de un cliente service worker que es un documento en un contexto de navegador, controlado por un worker activo. Es un tipo especial de objetoClient, con algunos métodos y propiedades adicionales disponibles.