O que são Workers:
Workers são uma Interface da API do Web Worker, que servem basicamente para executarmos tarefas em segundo (em uma thread paralela).
Como podemos utilizar isso?
Imagine que você tem um script extenso em execução nos bastidores, que não é vital para o funcionamento da sua aplicação. Esse script pode estar consumindo a thread principal, o que pararia toda a funcionalidade importante da plataforma. Isso é prejudicial, já que algo que não é essencial pode afetar negativamente a experiência do usuário. Aqui, https://www.youtube.com/watch?v=Gcp7triXFjg, temos um bom exemplo com código para explicar esse conceito. Você pode pular para o final do vídeo para ver o funcionamento.
O que é o Service Worker:
O Service Worker é um tipo especial de worker, baseado em eventos.
Destacamos os eventos porque uma de suas principais funcionalidades é a interceptação de requisições (fetch), ou seja, ele aguarda o evento de requisição (fetch) e pode manipular a solicitação, bem como armazenar em cache a resposta.
No entanto, ele possui limitações. Por trabalhar em um contexto separado (sendo um worker), ele não tem acesso ao DOM e, portanto, não pode realizar manipulações no HTML. Além disso, foi projetado para ser totalmente assíncrono, o que significa que não tem acesso ao localStorage.
Por uma questão de segurança ele só funcionam em ambientes locais ou ambientes HTTPS.
Como os service workers funcionam:
Vou começar apresentando o fluxo de vida de um service worker:
- Download
- Instalação
- Ativação
O seu primeiro Service Worker terá esse comportamento:
- O evento "install" é o primeiro evento que um service worker recebe, e ele acontece apenas uma vez.
- Uma promessa passada para installEvent.waitUntil() sinaliza a duração e o sucesso ou falha da sua instalação.
- Um service worker não receberá eventos como fetch e push até que ele seja instalado com sucesso e se torne "ativo".
- Por padrão, as solicitações de busca de uma página não passarão por um service worker, a menos que a solicitação da própria página tenha passado por um service worker. Portanto, será necessário atualizar a página para ver os efeitos do service worker.
- clients.claim() pode substituir essa configuração padrão e assumir o controle de páginas não controladas.
Vamos pegar esse HTML de exemplo:
<!DOCTYPE html>
An image will appear here in 3 seconds:
<script>
navigator.serviceWorker.register('/sw.js')
.then(reg => console.log('SW registered!', reg))
.catch(err => console.log('Boo!', err));
setTimeout(() => {
const img = new Image();
img.src = '/dog.svg';
document.body.appendChild(img);
}, 3000);
</script>
Ele registra um Service Worker, e adiciona a imagem de um cachorro depois de 3s
Aqui está o js do Service Worker, sw.js :
Ele cacheia a imagem de um gato, e a retorna quando faz um request para /dog.svg
Acesse este exemplo e preste muita atenção! Na primeira vez que você acessar, verá a imagem de um cachorro. No entanto, se você recarregar a página, verá a imagem de um gato.
Isso acontece porque o Service Worker passou por seu ciclo de vida na primeira vez que você acessou a página e, no segundo acesso, ele já havia feito o que lhe foi designado, ou seja, cacheou a imagem de um gato no pedido para o arquivo dog.svg.
É muito interessante o uso dos service workers, pois ele são a base para o offline first.
Conclusão:
Os Service Workers (SW) são muito importantes para as aplicações atuais, pois possibilitam um desempenho em um nível nunca visto na web. Isso inclui abordagens "offline first" e arquiteturas voltadas em torno dos Service Workers.
Aqui estão as minhas referências e links de apoio:
https://developer.mozilla.org/pt-BR/docs/Web/API/Service_Worker_API
https://developer.mozilla.org/pt-BR/docs/Web/API/Worker