La diferencia entre Web Sockets, Web Workers y Service Workers

Web Sockets, Web Workers, Service Workers… estos son términos que puede haber leído o escuchado por casualidad. Tal vez no todos ellos, pero probablemente al menos uno de ellos. E incluso si tiene un buen manejo del desarrollo front-end, es muy probable que necesite 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, vamos a desglosarlos juntos y distinguir Web Sockets, Web Workers y Service Workers. No en el sentido esencial en el que hacemos una inmersión profunda y obtenemos experiencia práctica con cada uno, más como un pequeño ayudante para marcar la próxima vez. I necesitas un repaso.

Referencia rápida

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

Feature	Lo que es
Zócalo web	Establece una conexión bidireccional abierta y persistente entre el navegador y el servidor para enviar y recibir mensajes a través de una única conexión desencadenada 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 de Servicios	Un tipo de Web Worker que crea un servicio en segundo plano que actúa como middleware para manejar las solicitudes de red entre el navegador y el servidor, incluso en situaciones fuera de línea.

Zócalos Web

Un Web Socket es un protocolo de comunicación bidireccional. Piense en esto como una llamada en curso entre usted y su amigo que no terminará a menos que uno de ustedes decida colgar. La única diferencia es que tú eres el navegador y tu amigo es el servidor. 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 hechos. A WebSocket El objeto se establece y se conecta a un servidor, y los mensajes entre el 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 una conexión y se mantiene viva hasta que el cliente o el servidor decida terminarla enviando un CloseEvent. Eso hace que Web Sockets sea ideal para aplicaciones que requieren una comunicación continua y directa entre un cliente y un servidor. La mayoría de las definiciones que he visto mencionan las 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á a punto de salir y decide encender 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 realiza un seguimiento donde quiera que vaya. Utiliza la transmisión de datos en tiempo real para realizar un seguimiento de su ubicación siempre que esta conexión esté activa. Eso es un Web Socket que establece una conversación bidireccional persistente entre el navegador y el servidor para mantener los datos actualizados. Una aplicación de deportes con puntajes en tiempo real también podría usar Web Sockets 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, los Web Sockets son parte del subproceso principal que les da la capacidad de manipular el DOM.

Existen herramientas y servicios para ayudar 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 lista en ejecución que incluye otros servicios.

Más información de WebSockets

Trabajadores web

Considere un escenario en el que necesita realizar un montón de cálculos complejos y, al mismo tiempo, realizar cambios en el DOM. JavaScript es una aplicación de un solo subproceso y la ejecución de más de un script puede interrumpir la interfaz de usuario en la que intenta realizar cambios, así como el complejo cálculo que se está realizando.

Aquí es donde entran en juego los Web Workers.

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. Eso los hace excelentes para mejorar el rendimiento de las aplicaciones que requieren operaciones intensivas, ya que 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 los 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 utilizando un Worker objeto de realizar las tareas. Y cuando hablamos de trabajadores, tienden a caer en uno de tres tipos:

• Trabajadores Dedicados: Un trabajador dedicado solo está al alcance del script que lo llama. Todavía ejecuta las tareas de un 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 prácticamente puede realizar cualquier tarea que ejecute un trabajador web, siempre que existan en el mismo dominio que el trabajador.
• Trabajadores de servicios: Un trabajador de servicio actúa como un proxy de red entre una aplicación, el navegador y el servidor, lo que permite que los scripts se ejecuten incluso en caso de que la red se desconecte. Vamos a llegar a esto en la siguiente sección.

Más información sobre 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 de un usuario. Cualquier red a la que se conecte un usuario es lo que es. Solo podemos hacer nuestro mejor esfuerzo 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 progresivamente el rendimiento de una aplicación. Un trabajador de servicio 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é necesitaría 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 falla por alguna razón desconocida. Eso rompería la comunicación entre el navegador y el servidor, evitando que los datos se transmitan de un lado a otro. Un 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 conoce como 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, obtener cosas previamente para que estén listas cuando el usuario las necesite y proporcionar respaldos en respuesta a errores de red. Son completamente asincrónicos pero, a diferencia de Web Sockets, no tienen acceso al DOM ya que se ejecutan en sus propios subprocesos.

La otra gran cosa que debe saber sobre los trabajadores de servicio es que interceptan cada solicitud y respuesta de su aplicación. Como tales, tienen algunas implicaciones de seguridad, sobre todo porque siguen una política del mismo origen. Entonces, eso significa no ejecutar un trabajador de servicio desde un CDN o un servicio de terceros. También requieren una conexión HTTPS segura, lo que significa que necesitará un certificado SSL para que se ejecuten.

Más información sobre trabajadores de servicios

Terminando

Esa 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 mezclarlos, pero espero que esto le dé una mejor idea de cómo distinguirlos.

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

Feature	Lo que es	¿Multiproceso?	¿HTTPS?	¿Acceso DOM?
Zócalo web	Establece una conexión bidireccional abierta y persistente entre el navegador y el servidor para enviar y recibir mensajes a través de una única conexión desencadenada por eventos.	Se ejecuta en el hilo principal	No se requiere	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	Requerido	No
Trabajador de Servicios	Un tipo de Web Worker que crea un servicio en segundo plano que actúa como 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	Requerido	No