Una Comparación de Web Workers

Hola, soy Thomas Hunter y esta charla es una comparación de web workers. El contenido de esta charla está adaptado de un libro que publiqué recientemente, Multithreaded JavaScript. Si deseas más sobre el libro, siéntete libre de seguir esa URL de bitly en la parte inferior de la pantalla.

Muy bien. Así que hoy vamos a hablar sobre tres temas separados. El primero es dedicated workers. El segundo es shared workers. Y el tercero es service workers. Cada uno de estos workers es un tipo de web worker.

Pero primero, en realidad voy a hablar sobre algunos conceptos básicos. Entonces, primero, el concepto de multithreading en JavaScript. Una cosa a tener en cuenta es que es la naturaleza de JavaScript y su ecosistema ser de un solo hilo. Así que durante mucho tiempo, realmente no existían capacidades verdaderas de multithreading en JavaScript. Puedes lograr algo de esto usando el paso de mensajes básico, usando iframes. Pero no era exactamente la solución más limpia. Sin embargo, ahora tenemos web workers disponibles para nosotros. Y con eso viene una característica llamada memoria compartida, que permite un mayor rendimiento y multithreading que solo usar el paso de mensajes. Esta presentación va a ser desde la perspectiva de usar estos web workers con un propósito de multithreading ya que está algo relacionado con el libro.

Muy bien. Así que otro concepto básico es, bueno, ¿qué es un entorno de JavaScript? Bueno, un entorno de JavaScript es una colección aislada de variables, globales, cosas como, ya sabes, el objeto con O mayúscula van a ser diferentes en estos entornos separados, las cadenas de prototipos, ya sabes, a qué terminan apuntando esos objetos son diferentes en estos diferentes entornos. Cada uno, cada entorno adicional va a incurrir en algún costo para iniciarse y así con Node es más fácil de medir. En mis experimentos fue aproximadamente cada nueva instancia de hilo de trabajo consume alrededor de seis megabytes de memoria. En un navegador vas a obtener algo más de sobrecarga. Los web workers incurrirán en algo de sobrecarga de memoria adicional y luego si tienes páginas adicionales hay aún más sobrecarga ya que hay diferentes documentos y rectángulos que necesitan ser renderizados.

Entonces, estas instancias de objetos que son creadas en estos diferentes entornos, nunca pueden ser realmente compartidas entre entornos. Sin embargo, puedes serializar estos objetos, puedes clonarlos de alguna manera, o puedes representarlos como JSON y luego pasarlos entre los entornos separados. Sin embargo, si mutas uno en un lugar, no lo estás mutando en el otro. Ninguno de los web workers que vamos a ver hoy tiene acceso al DOM. Así que, por ejemplo, el objeto global document no está disponible dentro de los web workers. Usando el shared array buffer, si pasas uno de esos entre estos diferentes entornos, un puntero a estos mismos datos binarios en memoria terminará siendo compartido y así es como podemos realizar el acceso a datos de memoria compartida.

Y gran parte de esta explicación es una especie de simplificación de algunas complejidades bajo el capó en relación con el contexto y los realms y realmente cómo funciona la máquina virtual de JavaScript.

Muy bien. Así que, ahora vamos a echar un vistazo a los dedicated workers. ¿Qué es un dedicated worker? Bueno, un dedicated worker es el más simple de los web workers que vamos a ver. Cada uno de estos dedicated workers puede tener exactamente un padre. De hecho, puedes terminar cargándolos como una jerarquía si quieres donde los dedicated workers pueden cargar otros dedicated workers también. Y cada uno de estos workers nos da un nuevo entorno de JavaScript. Cada uno también es capaz de ejecutarse en un hilo separado.

Así que, ahora, veamos un ejemplo de código. Así es como trabajaríamos con un dedicated worker desde el contexto de la página web. Así que, tal vez esto se encuentre en, como, un archivo index.html. Tal vez se encuentre dentro de main.js cargado por un archivo HTML. Pero en cualquier caso, esto se ejecuta dentro del hilo principal que dibuja la ventana. Y así, los navegadores modernos nos dan un Worker global con W mayúscula. Podemos instanciar eso para crear una instancia de un worker. El argumento para esto es la ruta a un archivo que queremos usar como el worker. Una vez que obtenemos el worker, podemos adjuntar un manejador de mensajes en él. Aquí estoy asignando este manejador de mensajes on message, que es una función de callback. Cuando esta función es llamada, va a imprimir el mensaje del worker y luego imprimir los datos que fueron pasados a ella. Este código se llamará dentro del hilo padre cuando el hilo del dedicated worker haya pasado un mensaje a él. Y luego, a la inversa, si queremos pasar un mensaje al worker, llamamos a worker.postmessage donde pasamos un argumento. Estoy pasando una cadena, pero podríamos pasar otros valores simples también o objetos básicos con algunas advertencias. Y luego finalmente, al final del archivo, solo estamos registrando que el final del archivo main.js se ha ejecutado.

Así que ahora veamos el dedicated worker dentro del worker. Así que este es nuestro archivo worker.js que fue referenciado en la diapositiva anterior. Así que en este archivo, lo primero que hacemos es simplemente registrar que estamos dentro del worker. Y luego asignamos un manejador de mensajes global, que acepta el mensaje que fue pasado desde el padre.

Así que vamos a ejecutar el código y ver la salida. Aquí ya lo he ejecutado para nosotros. Así que lo primero que vemos es el mensaje Hello from Main. Y luego, aunque pasamos el mensaje al hijo, terminamos registrando el mensaje Hello from the end of Main. Así que pasa una cantidad de tiempo no determinista antes de que el mensaje sea realmente recibido por el worker y procesado. Así que dentro de allí imprimimos hello from worker, y luego imprimimos from Main message to worker. Y finalmente, el mensaje que fue devuelto al hilo padre también se imprime. Así que del worker, mensaje del worker, ese es el mensaje final allí.

¿Y por qué podrías querer usar un dedicated worker? Bueno, la razón más importante en mi opinión es que da acceso a un hilo adicional. Y así, esta es una gran manera de descargar trabajo intensivo en CPU o cosas que de otro modo podrían ralentizar un navegador web. Cosas que podrían causar scroll jank, puedes descargar este hilo adicional. Y así pasas el mensaje al hilo y luego el hilo principal puede realizar otro trabajo. Y luego, una vez que recibe un mensaje de vuelta de ese dedicated worker, entonces puede manejar ese valor y luego continuar con lo que está haciendo. Una cosa a tener en cuenta es que un dedicated worker, cada vez que su único padre muere, ese dedicated worker también morirá.

Y a continuación, vamos a ver los shared workers. ¿Qué es un shared worker? Bueno, un shared worker es bastante similar, pero puede tener múltiples padres. Y así es útil para comunicarse a través de diferentes ventanas. Hay una advertencia de que estas ventanas necesitan estar en el mismo origen. Así que, por ejemplo, no puedes tener la página web de Google comunicándose con la página web de Microsoft. Tienen que seguir las mismas reglas de origen. Así que vamos a ver de nuevo un ejemplo de código. Y así primero vamos a ver el código que podría ejecutarse dentro de una página HTML. Y así podemos pretender que tenemos dos diferentes páginas HTML. Ambas tienen un script. Una es la HTML roja y la otra es la HTML azul. Y así dentro de estos archivos, tenemos como una etiqueta de script que está instanciando un shared worker. Así que el shared worker está disponible de nuevo en navegadores modernos con una pequeña advertencia que cubriré al final. Así que al igual que los otros workers, instanciamos el shared worker y pasamos un argumento, que es una ruta al archivo, para ser usado como el archivo del worker. Sin embargo, la API para interactuar con él es ligeramente diferente donde en lugar de asignar una propiedad onMessage directamente en el worker, la asignamos a un puerto. Y así esa propiedad de puerto representa un puerto de comunicación dentro del propio worker.

Y así la interfaz de otro modo, esto es bastante similar al dedicated worker donde es un callback que tomará un argumento de evento con una propiedad de datos que se pasa a él. En este caso, solo estamos registrando un mensaje que dice que recibimos un evento. Y luego, lo que queremos hacer más tarde es pasar un mensaje al shared worker desde uno de los archivos HTML. Y así para hacer eso, llamaríamos a worker.port.postMessage, pasando el mensaje que queremos pasarle.

Muy bien. Así que aquí hay algo de código sobre cómo usar el shared worker desde la perspectiva del worker. Así que este es nuestro archivo JavaScript del shared worker. Ahora, hay un poco de complejidad en aquí. Y trataré de explicar todo paso a paso. Pero realmente, el propósito de esto es solo mostrar cómo funciona el shared worker. Así que lo primero que hago en el shared worker es generar un ID. Así que ese número, es solo un gran número aleatorio para mostrar que este código solo se va a ejecutar una vez. Y así lo siguiente que hacemos es imprimir un mensaje de registro que estamos dentro del archivo shared.js y registramos ese ID nuevamente. A continuación, estamos creando una variable llamada ports. Y eso es un conjunto, y eso va a contener los puertos que se pasan a él. Después de eso, tenemos un método on connect que se asigna al self. Y así lo que esto es, esto es un callback que se llama cada vez que una página web diferente hace una conexión al shared worker. Así que si alguna vez has trabajado con web sockets, este patrón de código podría parecerte un poco familiar. Así que lo primero que hacemos es extraer el puerto de la conexión, y luego lo añadimos a nuestro conjunto de puertos. Y luego solo registramos que se ha hecho una conexión. Solo estamos registrando el ID nuevamente y también el tamaño de los puertos, lo que nos dirá cuántas páginas están conectadas.

Después de eso, asignamos un manejador de mensajes al puerto en sí, y eso dice que cuando este puerto recibe un mensaje. Así que cuando una de las páginas HTML envía un mensaje a este shared worker, queremos poder manejarlo aquí. Así que nuevamente, registraríamos el mensaje, diríamos que el mensaje fue recibido, el ID en los datos fue pasado. Ahora, anteriormente con el dedicated worker, cuando queríamos enviar un mensaje de vuelta al padre, era bastante sencillo. Había un solo puerto y solo publicaríamos el mensaje en él. Sin embargo, con los shared workers, dado que podemos tener más de un padre, es por eso que estamos colocando cada uno de los puertos en el conjunto de puertos, y luego estamos iterando sobre ellos aquí, y luego estamos llamando al post message en cada uno de ellos. Ahora, post message, solo nos permite enviar un solo valor a través de él. Sin embargo, en este caso, solo estoy abusando de un array para pasar el ID y los datos que se recibieron también. Y así digamos que realmente vamos adelante y ejecutamos este código en nuestra máquina.

Así que tal vez lo primero que hacemos es abrir el archivo red.html. Y entonces, ¿qué sucede?, vamos a ver que se ejecuta el archivo shared.js. Y vemos que se generó un ID. Ese ID es 1, 2, 3, 4, 5, 6. Y luego vemos que se establece una conexión. Y el red.html se ha conectado al shared worker. Y nuevamente, imprimimos ese ID.

Y el ID es el mismo. Luego abrimos el otro archivo. Abrimos el archivo blue.html. En ese momento, vemos que se emite la otra conexión. Y el ID se repite nuevamente. Y vemos que el número de conexiones ahora es dos. Y después de eso, ejecutamos el ejemplo de post message de hace dos diapositivas, donde pasamos el mensaje, hola, mundo, al shared worker. Y así, cuando eso sucede, el shared worker imprime que recibió un mensaje, imprime su ID nuevamente, y el mensaje que recibió. Y luego envía esos mensajes a los archivos HTML que llamaron. Y así, cuando eso sucede, se llama a la línea de eventos, las dos últimas líneas de eventos se imprimen en la pantalla.

Y esas se verán dentro de la consola para el inspector en esas páginas específicas. No hay ningún tipo de garantía en este caso, el orden en el que se hacen los registros de HTML azul. Esa es un poco la emoción divertida de la multithreading, que no siempre hay garantía sobre el orden en el que se ejecutan estas cosas. Entonces, ¿por qué podrías usar un shared worker? Bueno, tal vez necesites comunicarte entre páginas. Sabes, es bastante útil para mantener, como, un contexto con variables asociadas a él, y particularmente en casos donde quieres que esos alcances de variables sobrevivan a la vida de una página. Y así, tal vez algunas aplicaciones pesadas de una sola página puedan depender de esto. Realmente queremos coordinar cosas entre diferentes páginas. Entonces, otro patrón es tal vez quieras hacer un singleton, ya sabes, único, singleton, fuente de verdad, y quieres que sea accesible entre páginas. Una cosa a tener en cuenta es que, desafortunadamente, los shared workers no son compatibles con Safari. Creo que los soportaron en algún momento, pero luego por consideraciones de seguridad, terminaron eliminándolo. Sin embargo, funciona en Chrome y Firefox. Si te encuentras necesitando un patrón para coordinar la comunicación entre diferentes páginas, podrías considerar usar el broadcast channel como una alternativa, y eso está disponible en navegadores modernos también.

También puedes terminar manualmente estos web workers si así lo deseas. Muy bien, finalmente, echemos un vistazo a los service workers. ¿Qué es un service worker? Bueno, un service worker es el más complejo de los web workers. La característica más interesante que soportan es la capacidad de interceptar o de otra manera hacer proxy de las solicitudes que se hacen a un servidor desde una página web. Y así, esto incluye cosas como, oh, la solicitud fetch, solicitudes AJAX, pero también incluye cosas como imágenes que se cargan, recursos que se cargan desde CSS, el archivo favicon. Muchas de esas cosas, básicamente todo termina siendo enviado a través del service worker.

Una cosa interesante sobre el service worker es que técnicamente puede no tener padres, y de alguna manera vaga, se ejecuta en segundo plano. Y así, necesitas una página para ejecutar para terminar instalando el service worker. Pero luego, una vez que esa página se cierra, el service worker técnicamente permanece instalado en el navegador. El comportamiento sobre cuándo viene y va, cuándo vive y muere, eso está un poco menos definido en el sentido de que no es algo de lo que necesariamente querrías depender. Así que puedes usar los service workers para compartir estado entre ventanas del mismo origen también.

Muy bien. Así que veamos otro ejemplo de código. Así que, en este caso, cuando miramos los service workers como se ven en la página web, nuevamente, en este caso, la interfaz para crear el worker es un poco diferente. Aquí estamos llamando a navigator.service work.register. Al igual que con los otros web workers, el primer argumento es una ruta al archivo que representa el worker. También hay un objeto de configuración adicional, y la propiedad de configuración más comúnmente utilizada en esto es la de scope. Y así, el scope nos permite definir el rango de URL que el worker puede controlar. Así que, en este caso, estamos diciendo, ya sabes, las cosas que se cargan que comienzan con una barra terminan estando bajo control. Esencialmente está diciendo que todo en este dominio está bajo control. También obtenemos algunos cambios de estado diferentes a los que podemos enganchar. En este caso, estamos manejando el cambio de controlador, y solo vamos a registrar un mensaje en la pantalla. Así que, lo que eso dice es que, cuando la página actual, cuando un service worker termina tomando el control de la página, lo que significa que en ese momento las solicitudes son interceptadas, solo vamos a registrar un mensaje de que ahora está funcionando. Así que, la función final que tenemos aquí es la de hacer solicitud. Así que esto es solo con fines ilustrativos, y lo ejecutaremos en un momento. Pero lo que hace es simplemente hacer un fetch a un archivo en el servidor actual llamado data.json. Deserializa el resultado y luego lo registra en la pantalla. Muy bien, así que ahora echemos un vistazo a los service workers dentro del propio worker. Así que este es nuestro archivo sw.js. Esta es la primera mitad.

Entonces, lo primero que estamos haciendo aquí es crear una variable llamada counter y la estamos asignando a cero. A continuación, estamos asignando un método on install en nuestro objeto self y eso nos dice cuándo se está instalando el service worker. Así que, en este caso, solo vamos a registrar un mensaje de que la instalación ocurrió.

Después de eso, tenemos un on activate, y esto nos dice que se llama cuando el service worker alcanza la etapa o estado de activación, por así decirlo, estos service workers actúan como una máquina de estados. Entonces, esto sucede, solo vamos a registrar un mensaje de que el service worker ahora está activo, pero luego también vamos a hacer algo más que es un poco interesante. Cuando un service worker se activa por primera vez, cualquier página que esté abierta, las solicitudes que envíen no se enviarán inmediatamente a través de este service worker. No es hasta que la página se actualiza que esas páginas están bajo el control del service worker. Entonces, lo que estamos haciendo aquí en la parte inferior, estamos llamando a event.waitUntil, que acepta una promesa, y la promesa es el resultado de la llamada self.clients.claim. Así que, básicamente, eso está diciendo que las páginas que están actualmente abiertas, el service worker interceptará la solicitud. Muy bien.

Entonces, el archivo continúa, y aquí está la segunda mitad. También tenemos este manejador on fetch. Este manejador on fetch, se llama cada vez que el service worker recibe una solicitud de red de una de las páginas web. Así que, dentro de este, lo que estamos haciendo es primero registrar la URL que se recibió. A continuación, tenemos una declaración if, así que aquí, verificamos para ver si la URL que se recibió termina en data.json. Si no lo hace, entonces saltamos al final y recurrimos esencialmente a una solicitud HTTP normal. Así que, aquí, tenemos este evento que responde con, y eso acepta una promesa que se resuelve en un valor que se le da al navegador como resultado de la solicitud. Y así, el valor que le estamos dando es entonces la respuesta de fetch, que es una promesa, y luego el argumento que estamos proporcionando a fetch es la solicitud entrante, que es event.request. Así que, esencialmente, lo que esa línea está diciendo es simplemente realizar una solicitud normal y realmente no hacer nada con ella. Sin embargo, si la URL terminaba en data.JSON, ejecutamos el cuerpo de esa declaración if. Así que, lo que hacemos allí es incrementar esa variable counter de antes, y luego simplemente llamamos a event.respondWith, puedes ignorar ese return void, pero simplemente llamamos a event.respondWith, donde pasamos una nueva respuesta que estamos creando desde cero. Y así, el cuerpo de esa respuesta es un objeto JSON que contiene nuestro counter en la variable. Y luego, solo para fines ilustrativos, estamos configurando los encabezados, así que en este caso, estamos configurando el tipo de contenido a text.JSON. Y así, si realmente ejecutamos este código, estos son los registros que veremos. Así que, lo primero que vemos es que el service worker está instalado. A continuación, vemos que el service worker ha sido activado. Y luego, finalmente, vemos que el cambio de controlador ha ocurrido. Nuevamente, el orden de estos mensajes es no determinista, ya que el navegador, ya sabes, puede manejar un registro y almacenarlo en memoria. Bueno, imprimirá un registro desde otra ubicación. Así que, el orden de esto, esos primeros dos mensajes, no está garantizado.

Entonces, el orden de esto, esos dos primeros mensajes, no está garantizado. A continuación, llamamos a make request desde la página web, y eso hará nuestra solicitud fetch al servidor. Entonces, eso sucede. Imprimimos que se realizó el fetch. Solo imprime la URL que fue recibida, y luego devuelve el objeto JavaScript a través de la solicitud de red. Y luego, finalmente, el main.js recibe ese mensaje, y luego imprime el resultado, que en este caso es counter establecido en 1.

Y luego, si ejecutáramos la función make request varias veces, cada una de esas solicitudes resultaría en un counter diferente. Y así, ninguna de estas solicitudes realmente se envía a eso, al servidor que se ejecuta en el puerto localhost 500, todas son manejadas por el service worker. Entonces, ¿por qué podrías querer usar un service worker? Bueno, es realmente útil para almacenar en caché activos de red si una aplicación está sin conexión. Puedes usarlo para realizar sincronización en segundo plano de contenido que se actualiza, y si actualizas contenido en el servidor, el service worker puede entonces decidir cómo devolver eso al cliente. Si deseas poder admitir notificaciones push, eso también se hace en el service worker. Si eres como yo y te gusta construir aplicaciones web progresivas, y te gusta que esas aplicaciones se agreguen a la pantalla de inicio, bueno, tanto Android con Chrome como iOS con Safari harán uso de estos service workers, y es una especie de uno de los requisitos antes de que puedas agregar tu PWA a la pantalla de inicio. Una cosa a tener en cuenta es que un service worker, podría morir cuando muere el último padre, pero se queda por ahí y realmente no hay garantía de cuánto tiempo esas clausuras permanecen en memoria. Así que, si piensas en el ejemplo que tenía con esa variable counter, eso es en realidad un poco un anti-patrón. Realmente no querrías crear un estado en memoria en un service worker donde esperarías que se quedara. Y si deseas hacer cosas que sean un poco más persistentes, por ejemplo, quieres poner cosas en cachés. Hay todo tipo de APIs de caché que están disponibles dentro de los service workers para mantener esas cosas en un estado más persistente.

Así que, si fueras a tomar una captura de pantalla de esta presentación, probablemente esta sea la que hacer. Y así, aquí tenemos una especie de comparación entre los diferentes tipos de web workers. Y así, en el extremo izquierdo, tengo una especie de característica y luego cómo funciona para dedicated, shared y service workers. Y así, los tres de estos web workers, cada uno de ellos va a proporcionar un hilo adicional que podría usarse para propósitos de multi-threading. Si tienes un servidor que no está sirviendo contenido a través de HTTPS, pero solo puedes usar dedicated y shared workers, no puedes usar un service worker con él. Si necesitas soporte para Safari, puedes usar dedicated y service workers, pero tendrías que evitar un shared worker. Si deseas actuar como un proxy HTTP, bueno, entonces necesitas usar un service worker. Un dedicated worker tiene un padre, un shared worker tiene al menos un padre, y un service worker tiene al menos cero padres. Y luego un dedicated worker muere con su padre, un shared worker muere con su último padre, y un service worker, es un poco más complicado. Muy bien. Así que esa ha sido la presentación. Esta fue una comparación de web workers. Si deseas seguirme, estoy en Twitter en tlhunter. Esta presentación está disponible en ese enlace bit.ly en línea.