Como criar linhas de execução na Web com workers do módulo

Agora, mover trabalho pesado para linhas de execução em segundo plano é mais fácil com os módulos JavaScript em web workers.

Jason Miller

O JavaScript tem linha de execução única, ou seja, ele só pode executar uma operação por vez. Isso é intuitivo e funciona bem em muitos casos na Web, mas pode se tornar problemático quando precisamos realizar tarefas trabalhosas, como processamento de dados, análise, computação ou análise. À medida que aplicativos complexos são entregues na Web, há uma necessidade maior de processamento em várias linhas de execução.

Na plataforma da Web, o principal primitivo para linhas de execução e paralelismo é a API Web Workers (link em inglês). Os workers são uma abstração leve sobre as linhas de execução do sistema operacional que expõem uma API de transmissão de mensagens para comunicação entre linhas de execução. Isso pode ser extremamente útil ao realizar cálculos caros ou operar em grandes conjuntos de dados, permitindo que a linha de execução principal funcione sem problemas enquanto realiza as operações caras em uma ou mais linhas de execução em segundo plano.

Este é um exemplo típico de uso de workers, em que um script de worker detecta mensagens da linha de execução principal e responde enviando mensagens próprias:

page.js:

const worker = new Worker('worker.js');
worker.addEventListener('message', e => {
  console.log(e.data);
});
worker.postMessage('hello');

worker.js:

addEventListener('message', e => {
  if (e.data === 'hello') {
    postMessage('world');
  }
});

A API Web Worker está disponível na maioria dos navegadores há mais de dez anos. Embora os workers tenham excelente suporte a navegadores e sejam bem otimizados, isso também significa que eles antecedem muito os módulos JavaScript. Como não havia um sistema de módulos quando os workers foram criados, a API para carregar código em um worker e escrever scripts permaneceu semelhante às abordagens de carregamento síncrono de scripts comuns em 2009.

Histórico: workers clássicos

O construtor Worker usa um URL de script clássico, que é relativo ao URL do documento. Ele retorna imediatamente uma referência à nova instância de worker, que expõe uma interface de mensagens, bem como um método terminate() que interrompe e destrói o worker imediatamente.

const worker = new Worker('worker.js');

Uma função importScripts() está disponível nos workers da Web para carregar código adicional, mas pausa a execução do worker para buscar e avaliar cada script. Ele também executa scripts no escopo global como uma tag <script> clássica, o que significa que as variáveis em um script podem ser substituídas pelas variáveis em outro.

worker.js:

importScripts('greet.js');
// ^ could block for seconds
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

// global to the whole worker
function sayHello() {
  return 'world';
}

Por esse motivo, os web workers sempre impuseram um efeito maior sobre a arquitetura de um aplicativo. Os desenvolvedores tiveram que criar ferramentas e soluções alternativas inteligentes para possibilitar o uso de workers da Web sem abrir mão das práticas modernas de desenvolvimento. Por exemplo, bundlers, como o webpack, incorporam uma pequena implementação de carregador de módulo ao código gerado que usa importScripts() para o carregamento de código, mas envolve módulos em funções para evitar colisões de variáveis e simular importações e exportações de dependência.

Inserir workers do módulo

Um novo modo para workers da Web que oferece os benefícios de ergonomia e desempenho dos módulos JavaScript, será lançado no Chrome 80, chamado de workers do módulo. O construtor Worker agora aceita uma nova opção {type:"module"}, que muda o carregamento e a execução do script para corresponder a <script type="module">.

const worker = new Worker('worker.js', {
  type: 'module'
});

Como os workers de módulo são módulos JavaScript padrão, eles podem usar instruções de importação e exportação. Assim como em todos os módulos JavaScript, as dependências são executadas apenas uma vez em determinado contexto (linha de execução principal, worker etc.), e todas as importações futuras fazem referência à instância do módulo já executada. O carregamento e a execução de módulos JavaScript também são otimizados pelos navegadores. As dependências de um módulo podem ser carregadas antes da execução do módulo, o que permite que árvores inteiras de módulos sejam carregadas em paralelo. O carregamento de módulo também armazena em cache o código analisado, o que significa que os módulos usados na linha de execução principal e em um worker só precisam ser analisados uma vez.

A mudança para módulos JavaScript também permite o uso da importação dinâmica para códigos de carregamento lento sem bloquear a execução do worker. A importação dinâmica é muito mais explícita do que usar importScripts() para carregar dependências, já que as exportações do módulo importado são retornadas em vez de dependerem de variáveis globais.

worker.js:

import { sayHello } from './greet.js';
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

import greetings from './data.js';
export function sayHello() {
  return greetings.hello;
}

Para garantir um ótimo desempenho, o método importScripts() antigo não está disponível nos workers do módulo. Alternar workers para usar módulos JavaScript significa que todo o código é carregado no modo estrito. Outra mudança notável é que o valor de this no escopo de nível superior de um módulo JavaScript é undefined, enquanto que nos workers clássicos o valor é o escopo global do worker. Felizmente, sempre houve um self global que fornece uma referência ao escopo global. Ela está disponível em todos os tipos de workers, incluindo service workers e no DOM.

Pré-carregar workers com modulepreload

Uma melhoria substancial de desempenho que acompanha os workers do módulo é a capacidade de pré-carregar os workers e as dependências deles. Com os workers do módulo, os scripts são carregados e executados como módulos JavaScript padrão, o que significa que eles podem ser pré-carregados e até mesmo pré-analisados usando modulepreload:

<!-- preloads worker.js and its dependencies: -->
<link rel="modulepreload" href="worker.js">

<script>
  addEventListener('load', () => {
    // our worker code is likely already parsed and ready to execute!
    const worker = new Worker('worker.js', { type: 'module' });
  });
</script>

Os módulos pré-carregados também podem ser usados pela linha de execução principal e pelos workers do módulo. Isso é útil para módulos importados em ambos os contextos ou nos casos em que não é possível saber com antecedência se um módulo será usado na linha de execução principal ou em um worker.

Anteriormente, as opções disponíveis para pré-carregar scripts de worker da Web eram limitadas e não necessariamente confiáveis. Os workers clássicos tinham o próprio tipo de recurso "worker" para o pré-carregamento, mas nenhum navegador implementou <link rel="preload" as="worker">. Como resultado, a técnica principal disponível para pré-carregamento de workers da Web era usar <link rel="prefetch">, que dependia inteiramente do cache HTTP. Quando usada em combinação com os cabeçalhos de armazenamento em cache corretos, foi possível evitar que a instanciação do worker tivesse que esperar para fazer o download do script dele. No entanto, ao contrário de modulepreload, essa técnica não oferece suporte ao pré-carregamento de dependências ou à preparação.

E os workers compartilhados?

Os workers compartilhados foram atualizados para oferecer suporte a módulos JavaScript a partir do Chrome 83. Assim como os workers dedicados, a criação de um worker compartilhado com a opção {type:"module"} agora carrega o script dele como um módulo em vez de um script clássico:

const worker = new SharedWorker('/worker.js', {
  type: 'module'
});

Antes do suporte aos módulos JavaScript, o construtor SharedWorker() esperava apenas um URL e um argumento name opcional. Isso continuará funcionando para o uso de workers compartilhados clássicos. No entanto, para criar workers compartilhados de módulos, é necessário usar o novo argumento options. As opções disponíveis são as mesmas de um worker dedicado, incluindo a opção name, que substitui o argumento name anterior.

E quanto ao service worker?

A especificação do service worker já foi atualizada para oferecer suporte à aceitação de um módulo JavaScript como ponto de entrada, usando a mesma opção {type:"module"} que os workers do módulo. No entanto, essa mudança ainda não foi implementada nos navegadores. Quando isso acontecer, será possível instanciar um service worker usando um módulo JavaScript com o seguinte código:

navigator.serviceWorker.register('/sw.js', {
  type: 'module'
});

Agora que a especificação foi atualizada, os navegadores estão começando a implementar o novo comportamento. Isso leva tempo, porque há algumas complicações extras associadas à transferência de módulos JavaScript para o service worker. O registro de service workers precisa comparar scripts importados com versões anteriores em cache ao determinar se uma atualização precisa ser acionada. Isso precisa ser implementado em módulos JavaScript quando usados para service workers. Além disso, os service workers precisam ser capazes de ignorar o cache de scripts em determinados casos ao verificar se há atualizações.

Outros recursos e leituras