La diferencia entre sockets web, trabajadores web y trabajadores de servicios | trucos CSS

Web Sockets, Web Workers, Service Workers... estos son términos que puede haber leído o escuchado. Tal vez no todos, pero lo más probable es que al menos uno de ellos. E incluso si eres bueno en el desarrollo front-end, es muy probable que debas buscar lo que significan. O tal vez eres como yo y los mezclas de vez en cuando. Todos los términos se ven y suenan terriblemente similares, y es muy fácil confundirlos.

Entonces, dividámoslos y diferenciémoslos entre sockets web, trabajadores web y trabajadores de servicios. No en el pequeño sentido en el que hacemos una inmersión profunda y obtenemos experiencia práctica con cada uno, más bien como un pequeño ayudante para tomar nota la próxima vez. yo necesitas un refrigerio.

Referencia rápida

Comenzaremos con una descripción general de alto nivel para una comparación y contraste rápidos.

Una característica	Que es
WebSocket	Establece una conexión bidireccional abierta y persistente entre el navegador y el servidor para enviar y recibir mensajes a través de una conexión activada por eventos.
trabajador web	Permite que los scripts se ejecuten en segundo plano en subprocesos separados para evitar que los scripts se bloqueen entre sí en el subproceso principal.
Trabajador del servicio	Un tipo de trabajador web que crea un servicio en segundo plano que actúa como un middleware para manejar las solicitudes de red entre el navegador y el servidor, incluso en situaciones fuera de línea.

WebSockets

Web Socket es un protocolo de comunicación bidireccional. Piense en ello como una conversación en curso entre usted y su amigo que no terminará a menos que uno de ustedes decida colgar. La única diferencia es que usted es el navegador y su amigo es El cliente envía una solicitud al servidor y el servidor responde procesando la solicitud del cliente y viceversa.

La comunicación se basa en eventos. WebSocket el objeto se establece y se conecta a un servidor, y los mensajes de servidor a servidor desencadenan eventos que los envían y reciben.

Esto significa que cuando se realiza la conexión inicial, tenemos una comunicación cliente-servidor en la que se inicia la conexión y se mantiene viva hasta que el cliente o el servidor decida terminarla enviando CloseEventEsto hace que Web Sockets sea ideal para aplicaciones que requieren una comunicación continua y directa entre el cliente y el servidor. La mayoría de las definiciones que he visto invocan aplicaciones de chat como un caso de uso común: escribe un mensaje, lo envía al servidor, activa un evento y el servidor responde con datos sin tener que hacer ping al servidor una y otra vez.

Considere este escenario: Estás a punto de salir y decides activar Google Maps. Probablemente ya sepa cómo funciona Google Maps, pero si no lo sabe, encuentra su ubicación automáticamente después de conectarse a la aplicación y la sigue a donde quiera que vaya. Utiliza la transmisión de datos en tiempo real para rastrear su ubicación mientras esta conexión está activa. Este es un socket web que establece una conversación bidireccional constante entre el navegador y el servidor para mantener estos datos actualizados. la aplicación de resultados en tiempo real también puede usar websockets de esta manera.

La gran diferencia entre Web Sockets y Web Workers (y, por extensión, como veremos, Service Workers) es que tienen acceso directo al DOM. Mientras que Web Workers (y Service Workers) se ejecutan en subprocesos separados, Web Sockets son parte del hilo principal, dándoles la capacidad de manipular el DOM.

Existen herramientas y servicios que ayudan a establecer y mantener conexiones Web Socket, que incluyen: Clúster de sockets, API asíncrona, vaquero, WebSocket Rey, Canalesy Gorila WebSocket.MDN tiene un una lista de trabajo que incluye otros servicios.

Más información sobre WebSockets

trabajadores web

Considere un escenario en el que necesita realizar un montón de cálculos complejos mientras realiza cambios en el DOM. JavaScript es una aplicación de un solo subproceso, y ejecutar más de un script puede romper la interfaz de usuario que intenta modificar, así como el cálculo complejo que se realiza.

Aquí es donde entran en juego los trabajadores web.

Web Workers permite que los scripts se ejecuten en segundo plano en subprocesos separados para evitar que los scripts se bloqueen entre sí en el subproceso principal. Esto los hace excelentes para mejorar el rendimiento de las aplicaciones que requieren operaciones intensivas, porque esas operaciones se pueden realizar en segundo plano en subprocesos separados sin afectar la representación de la interfaz de usuario. Pero no son tan buenos para acceder al DOM porque, a diferencia de Web Sockets, un trabajador web se ejecuta fuera del subproceso principal en su propio subproceso.

Un Web Worker es un objeto que ejecuta un archivo de script usando un Worker objeto para realizar tareas Y cuando hablamos de trabajadores, tienden a caer en uno de tres tipos:

• Trabajadores dedicados: Un trabajador dedicado solo está disponible para el script que lo llama. Todavía realiza las tareas de trabajador web típico, como sus scripts de subprocesos múltiples.
• trabajadores compartidos: Un trabajador compartido es lo opuesto a un trabajador dedicado. Se puede acceder a él mediante varios scripts y puede realizar prácticamente cualquier tarea que realiza un trabajador web, siempre que exista en el mismo dominio que el trabajador.
• Trabajadores de servicios: Un Service Worker actúa como un proxy de red entre una aplicación, un navegador y un servidor, lo que permite que los scripts se ejecuten incluso cuando la red está desconectada. Llegaremos a eso en la siguiente sección.

Más información sobre los trabajadores web

trabajadores de servicio

Hay algunas cosas sobre las que no tenemos control como desarrolladores, y una de esas cosas es la conexión de red del usuario. Sea cual sea la red a la que se conecte el usuario, lo es. Solo podemos hacer todo lo posible para optimizar nuestras aplicaciones para que funcionen lo mejor posible en cualquier conexión que se utilice.

Los Service Workers son una de las cosas que podemos hacer para mejorar gradualmente el rendimiento de una aplicación. Un Service Worker se encuentra entre la aplicación, el navegador y el servidor, proporcionando una conexión segura que se ejecuta en segundo plano en un subproceso separado, gracias a, lo adivinó, Web Workers. Como aprendimos en la última sección, los Service Workers son uno de los tres tipos de Web Workers.

Entonces, ¿por qué necesita un trabajador de servicio entre su aplicación y el navegador del usuario? Nuevamente, no tenemos control sobre la conexión de red del usuario. Digamos que la conexión se cae por algún motivo desconocido. Esto rompería la comunicación entre el navegador y el servidor, evitando que los datos se transmitan de un lado a otro. El trabajador del servicio mantiene la conexión actuando como un proxy asíncrono que es capaz de interceptar solicitudes y ejecutar tareas, incluso después de que se pierde la conexión de red.

Este es el principal impulsor de lo que a menudo se denomina desarrollo "fuera de línea primero". Podemos almacenar activos en la memoria caché local en lugar de en la red, proporcionar información crítica si el usuario se desconecta, buscar cosas previamente para que estén listas cuando el usuario las necesite. ellos y proporciona respaldos en respuesta a errores de red.Son completamente asincrónicos, pero a diferencia de Web Sockets, no acceden al DOM porque se ejecutan en sus propios subprocesos.

La otra cosa importante que debe saber sobre los Service Workers es que interceptan todas las solicitudes y respuestas de su aplicación. Como tales, tienen algunas implicaciones de seguridad, sobre todo porque siguen una política del mismo origen. Esto significa que no se está ejecutando ningún servicio de trabajador de CDN o servicio de terceros. También requieren una conexión HTTPS segura, lo que significa que necesitará un certificado SSL para que funcionen.

Más información sobre los Trabajadores de Servicios

resumiendo

Esta es una explicación de muy alto nivel de las diferencias (y similitudes) entre Web Sockets, Web Workers y Service Workers. Nuevamente, la terminología y los conceptos son lo suficientemente similares como para confundirse entre sí, pero espero que esto le dé una mejor idea de cómo diferenciarlos.

Comenzamos con una tabla de referencia rápida. Aquí está lo mismo, pero ligeramente ampliado para hacer comparaciones más completas.

Una característica	Que es	¿Multiproceso?	¿HTTPS?	¿Acceso DOM?
WebSocket	Establece una conexión bidireccional abierta y persistente entre el navegador y el servidor para enviar y recibir mensajes a través de una conexión activada por eventos.	Funciona en el hilo principal.	No necesariamente	Sí
trabajador web	Permite que los scripts se ejecuten en segundo plano en subprocesos separados para evitar que los scripts se bloqueen entre sí en el subproceso principal.	Se ejecuta en un hilo separado.	Obligatorio	No
Trabajador del servicio	Un tipo de trabajador web que crea un servicio en segundo plano que actúa como un middleware para manejar las solicitudes de red entre el navegador y el servidor, incluso en situaciones fuera de línea.	Se ejecuta en un hilo separado.	Obligatorio	No