javascript - link - Trabajador de servicio vs trabajador compartido
title html (2)
¿Cuál es la diferencia entre Service Worker y Shared Worker?
¿Cuándo debo usar Service Worker en lugar de Shared Worker y viceversa?
Un contexto SharedWorker es una sesión con estado y está diseñado para multiplexar páginas web en una sola aplicación a través de mensajes asíncronos (paradigma cliente / servidor). Su ciclo de vida se basa en el dominio , en lugar de en una sola página como DedicatedWorker (paradigma de dos niveles).
Un contexto de ServiceWorker está diseñado para ser sin estado . En realidad, no es una sesión persistente en absoluto, es la inversión de control (IoC) o el paradigma del servicio de persistencia basado en eventos. Sirve eventos, no sesiones.
Un propósito es servir eventos asíncronos seguros concurrentes para consultas de larga ejecución (LRQ) a bases de datos y otros servicios de persistencia (es decir, nubes). Exactamente lo que hace un grupo de subprocesos en otros idiomas.
Por ejemplo, si su aplicación web ejecuta muchos LRQ seguros concurrentes a varios servicios en la nube para poblarse, los trabajadores del servicio son lo que usted desea. Puede ejecutar docenas de LRQ seguros al instante, sin bloquear la experiencia del usuario. SharedWorkers y DedicatedWorkers no son fácilmente capaces de manejar muchos LRQ seguros concurrentes. Además, algunos navegadores no admiten SharedWorkers .
Quizás deberían haber llamado a ServiceWorkers en su lugar: CloudWorkers para mayor claridad, pero no todos los servicios son nubes.
Esperamos que esta explicación lo lleve a pensar cómo se diseñaron los distintos tipos de Trabajadores para que trabajen juntos. Cada uno tiene su propia especialización, pero el objetivo común es reducir la latencia del DOM y mejorar la experiencia del usuario en aplicaciones basadas en web.
Agregue algunos WebSockets para notificaciones automáticas y WebGL para gráficos y puede crear algunas aplicaciones web para fumar que funcionan como juegos de consola multijugador .
Un trabajador de servicio tiene una funcionalidad adicional más allá de lo que está disponible en trabajadores compartidos, y una vez que se registra, se mantiene fuera de la vida útil de una página web determinada.
Los trabajadores de servicios pueden responder a eventos de message , como trabajadores compartidos, pero también tienen acceso a eventos adicionales. El manejo de eventos de fetch permite a los trabajadores del servicio interceptar cualquier tráfico de red (que se origina en una página controlada) y tomar acciones específicas, incluyendo respuestas de servicio desde un caché de Request / Response . También hay plans para exponer un evento push a los trabajadores de servicio, permitiendo que las aplicaciones web reciban mensajes push en el "fondo".
La otra gran diferencia se relaciona con la persistencia. Una vez que un trabajador de servicios se registra para un origen y alcance específicos, permanece registrado indefinidamente. (El trabajador de servicio se actualizará automáticamente si el script subyacente cambia, y puede eliminarse de forma manual o programada, pero esa es la excepción). Porque el trabajador de servicio es persistente y tiene una vida independiente de las páginas activas en un navegador web. , abre la puerta a cosas como usarlas para alimentar el mensaje push mencionado anteriormente: un trabajador de servicio puede ser "despertado" y procesar un evento push siempre que el navegador esté en funcionamiento, independientemente de qué páginas estén activas. Es probable que las características futuras de la plataforma web también aprovechen esta persistencia.
Existen otras diferencias técnicas, pero desde una visión de nivel superior, esas son las que se destacan.