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

Transferir a carga pesada para threads de segundo plano ficou mais fácil com os módulos JavaScript em web workers.

Jason miller

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

Na plataforma da Web, o principal primitivo para linhas de execução e paralelismo é a API Web Workers. 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 imensamente útil ao realizar cálculos caros ou operar em grandes conjuntos de dados, permitindo que a linha de execução principal seja executada sem problemas ao mesmo tempo que realiza operações dispendiosas em uma ou mais linhas de execução em segundo plano.

Veja um exemplo típico de uso de worker, 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 isso significa que os workers tenham excelente suporte ao navegador e sejam bem otimizados, também significa que eles demoram muito tempo nos módulos JavaScript. Como não havia um sistema de módulos quando os workers foram projetados, a API para carregar código em um worker e compor scripts permaneceu semelhante às abordagens comuns de carregamento de script síncrono em 2009.

Histórico: workers clássicos

O construtor do worker usa um URL de script clássico, que é relacionado 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 destrua imediatamente.

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

Uma função importScripts() está disponível em workers da Web para carregar outro código, 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 de grande escala na arquitetura de um aplicativo. Os desenvolvedores tiveram que criar ferramentas inteligentes e soluções alternativas para possibilitar o uso de Web workers sem desistir das práticas modernas de desenvolvimento. Por exemplo, bundlers como webpack incorporam uma pequena implementação do carregador de módulo no código gerado que usa importScripts() para o carregamento de código, mas encapsula os 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 Web workers com os benefícios de ergonomia e desempenho dos módulos JavaScript está sendo lançado no Chrome 80, chamado de workers de módulos. O construtor Worker agora aceita uma nova opção {type:"module"}, que altera 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 um determinado contexto (linha de execução principal, worker etc.), e todas as importações futuras se referem à 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 do módulo ser executado, o que permite que árvores inteiras do módulo sejam carregadas em paralelo. O carregamento do 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 o carregamento lento do código 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 depender 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 os workers para usar módulos JavaScript significa que todo o código é carregado no modo estrito. Outra mudança importante é que o valor de this no escopo de nível superior de um módulo JavaScript é undefined. Já em workers clássicos, o valor é o escopo global do worker. Felizmente, sempre houve um self global que fornece uma referência ao escopo global. Ele está disponível em todos os tipos de workers, incluindo service workers e no DOM.

Pré-carregar workers com modulepreload.

Uma melhoria substancial no desempenho dos workers de módulo é a capacidade de pré-carregar os workers e as dependências deles. Com os workers de 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.

Antes, as opções disponíveis para pré-carregamento de scripts de workers da Web eram limitadas e não necessariamente confiáveis. Os workers clássicos tinham o próprio tipo de recurso "worker" para pré-carregamento, mas nenhum navegador implementou <link rel="preload" as="worker">. Como resultado, a técnica principal disponível para pré-carregamento de Web workers 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, isso tornou possível evitar que a instanciação do worker tivesse que esperar para fazer o download do script do worker. No entanto, ao contrário de modulepreload, essa técnica não permitia o pré-carregamento de dependências ou a pré-análise.

E os workers compartilhados?

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

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

Antes do suporte a módulos JavaScript, o construtor SharedWorker() esperava apenas um URL e um argumento name opcional. Isso continuará funcionando para o uso clássico do worker compartilhado. No entanto, a criação de workers compartilhados do módulo requer o uso do 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 o service worker?

A especificação do service worker já foi atualizada para aceitar um módulo JavaScript como ponto de entrada, usando a mesma opção {type:"module"} dos workers de 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 adicionais associadas ao uso de módulos JavaScript para o service worker. O registro do service worker precisa comparar scripts importados com as versões anteriores em cache ao determinar se precisa acionar uma atualização, e isso precisa ser implementado para módulos JavaScript quando usado para service workers. Além disso, os service workers precisam ignorar o cache de scripts em determinados casos ao verificar se há atualizações.

Recursos adicionais e leituras adicionais