Tentando descobrir o que é um service worker? Você não está sozinho!
Um Service Worker é um script executado em segundo plano, em um thread separado da IU do navegador. O cache do Service Worker possibilita que um site funcione offline. Eles são a potência técnica que eleva o nível de um site a um aplicativo da web progressivo . Eles permitem uma integração profunda da plataforma, como cache avançado, notificações push e sincronização em segundo plano.
Service workers são projetados para serem uma plataforma extensível; recursos adicionais estão sendo planejados.
Eles não podem acessar o DOM, mas podem interceptar todas as solicitações da rede. Isso permite que os desenvolvedores tenham a oportunidade de controlar como as solicitações são tratadas, fornecendo uma maneira rica de fazer os sites funcionarem offline.
Os service workers são considerados uma virada de jogo para a web. Não acho que seja um simples exagero, porque eles permitem muitos recursos necessários e tornam nativa a arquitetura central que usei durante anos.
Trabalhadores de serviço parecem incríveis!
Esta é a tecnologia-chave ou API da web moderna por trás dos Progressive Web Applications. Sem um prestador de serviço, um site é apenas um site, adicione um prestador de serviço e você terá um aplicativo.
Existem alguns recursos importantes sobre os prestadores de serviço que você precisa entender:
- Um Service Worker é um arquivo JavaScript
- Eles são executados em uma thread separada da IU
- Eles não podem acessar o DOM diretamente
- Lá é um ciclo de vida ou uma série de eventos pelos quais um prestador de serviço passa para se tornar ativo, explicado mais tarde
- Eles só ficam ativos durante o uso, portanto, não há desgaste da bateria
- Eles estão isolados no origem ou domínio no qual eles estão registrados
- Os prestadores de serviço exigem HTTPS
- Podem enviar mensagens de e para a IU
- Não exigem uma página da web aberta para funcionar
- São suportados por todos os principais navegadores, incluindo iOS Safari
- São semelhantes aos Web Workers, mas melhores em muitos aspectos
Como funcionam os prestadores de serviço?
Um Service Worker fica entre o navegador e a rede, agindo como um servidor proxy, lidando com uma coleção de tarefas não centradas na IU. Eles são orientados por eventos e vivem fora do processo do navegador, permitindo que funcionem sem uma sessão ativa do navegador. O service worker é um script executado em um thread, separado da IU. Isso permite que o service worker execute tarefas não relacionadas à IU, melhorando o desempenho de um site.
Os funcionários do serviço são encerrados quando não estão em uso e são restaurados quando necessário, o que evita que sobrecarreguem a CPU e esgotem as baterias. Eles agem como um proxy de rede programável ou intermediário entre o navegador e a rede, capacitando os desenvolvedores a projetar como as solicitações de rede são tratadas.
O primeiro poder que um prestador de serviço traz para um site é a capacidade de habilitar recursos off-line com controle granular. Isso é feito com uma API de cache avançada e interceptando todas as solicitações de rede antes que elas saiam.
O armazenamento em cache não permite apenas experiências offline, os sites podem carregar instantaneamente quando recuperados do cache. O armazenamento em cache do Service Worker torna a rede um aprimoramento progressivo ou não é necessário para tornar o site utilizável.
Extensibilidade do Service Worker
Um recurso subestimado do service worker é sua extensibilidade. Service workers são projetados para serem a espinha dorsal que oferece suporte a funcionalidades adicionais. Os primeiros dois recursos enviados em navegadores são notificações push nativas e sincronização em segundo plano. Mais novas APIs estão sendo debatidas e devem começar a aparecer nos navegadores em um futuro próximo.
Service workers vivem em seu próprio thread e não têm acesso ao DOM. Eles também têm seu próprio escopo global, referido usando o objeto’self’.
Também exigem que um site seja veiculado usando HTTPS. Esse requisito se deve aos recursos poderosos que os service workers oferecem. HTTPS evita muitos ataques comuns. Hoje, todos os sites devem ser atendidos usando HTTPS, pois as barreiras de implementação foram removidas e a quantidade mínima de segurança que eles oferecem.
Eles também são assíncronos. Isso significa que todas as APIs suportam promessas. Isso também significa que certas APIs e funções não estão acessíveis em service workers. O mais notável é localStorage. Em vez disso, os dados devem ser armazenados usando IndexedDB.
Ciclo de vida do Service Worker
Antes de mergulhar nesses excelentes recursos para prestadores de serviço, os desenvolvedores precisam entender o ciclo de vida.
Um prestador de serviço deve ser registrado em um site. Como alguns navegadores ainda não oferecem suporte a service workers, você deve executar uma verificação de recurso antes de registrar um service worker. Isso é feito verificando a presença de’serviceWorker’no navegador.
if ('serviceWorker'no navegador) { navigator.serviceWorker.register ('/sw.js') .então (função (registro) { //Registro realizado com sucesso }) .catch (function (err) { //registração falhou:( }); }
Para registrar o service worker, chame navigator.serviceWorker.register. Passe o caminho para o service worker. A função de registro retorna uma promessa.
Se for bem-sucedida, a promessa retorna uma referência ao objeto de registro do service worker. A partir daí, você pode executar tarefas específicas da IU conforme necessário.
Eventos padrão de service workers
- install
- activate
- fetch
- push (não suportado pelo Safari)
- sincronização (não suportado pela maioria navegadores ainda)
Quando um service worker é registrado, o evento”install”. Nesse caso, a tarefa mais comum a ser realizada é chamada de pré-armazenamento em cache.
Pré-cache é onde uma lista predefinida de arquivos de ativos necessários para formar uma página ou site e adicioná-los ao cache antes de serem solicitados. Isso aproveita o cache do service worker para persistir essas respostas.
self.addEventListener ("install", event=& amp; amp; gt; { event.waitUntil ( caches.open (preCacheName) .então (função (cache) { return cache.addAll (precache_urls); }) ); });
O evento de instalação só é acionado uma vez na vida do trabalhador do serviço. O evento não será acionado novamente até que o service worker seja atualizado.
O próximo evento disparado como parte do ciclo de vida do registro é’ativar’. Quando um service worker é instalado, ele não se torna imediatamente ativo. A sequência natural é um novo service worker esperar até que todos os service workers’clientes’sejam fechados.
O motivo pelo qual os service workers são projetados para não assumir o controle imediatamente é para evitar que interrompam a experiência do usuário.
A função skipWaiting força um service worker em espera a se tornar ativo. Isso só deve ser usado quando você tiver certeza de que o novo prestador de serviço não quebrará nenhum cliente existente.
self.skipWaiting ();
Assim que o service worker se torna ativo, o evento’activate’é disparado.
self.addEventListener ("activate", event=& amp; amp; gt; { //na ativação event.waitUntil (clients.claim ()); });
Este evento é comumente usado para realizar qualquer tarefa de limpeza ou migração. Por exemplo, remover caches legados que podem entrar em conflito com os novos caches de service workers.
Quanto tempo dura para os funcionários do serviço?
Não existe uma regra rígida sobre por quanto tempo um navegador mantém um service worker em execução. Internamente, o mecanismo do navegador usará um conjunto de heurísticas para determinar quando encerrar o processo de trabalho do serviço.
Em geral, se uma página da web está inativa, o processo diminui após um ou dois minutos, talvez em até 30 segundos.
A realidade é que o tempo exato dependerá do hardware, dos padrões de uso etc.
A boa notícia é que leva alguns milissegundos para ativar um Service Worker. É tão rápido que você nem notará nenhuma latência. Você também não precisa programar nada especial para lidar com um cenário sem o service worker, seu site simplesmente funcionará. A magia do aprimoramento progressivo.
Como posso verificar se um Service Worker está registrado?
Existem várias maneiras de verificar se um service worker está registrado. O mais fácil é chamar o método serviceworkers.getRegistrations.
navigator.serviceWorker.getRegistrations (). then (registrations=& amp; amp; gt; { console.log (registros); });
Este é o código que você pode adicionar ao script de suas páginas para registrar o registro para suporte técnico ou depuração do desenvolvedor.
O método’getRegistrations’retorna uma matriz de todos os service workers registrados no escopo ou site atual.
Se você está apenas registrando o registro no console, é melhor visualizar a guia’Aplicativo’das Ferramentas de Desenvolvimento. Ele tem um subpainel que exibe um visual do prestador de serviço registrado da origem. Você também pode acionar eventos de sincronização em segundo plano e testar notificações push.
Você também pode excluir o service worker, forçar uma atualização e outro gerenciamento geral que ajude no desenvolvimento.
O valor real que getRegistrations oferece é algum tipo de recurso de suporte indireto. Todos nós sabemos o que é tentar ajudar alguém remotamente e você não pode acessar as DevTools para realmente solucionar o problema. Às vezes, você desejará algum tipo de página de suporte visual ou modal para fornecer informações sobre o estado do aplicativo.
O consumidor médio não saberá como acessar o painel do console do DevTools. Em vez disso, você pode criar uma interface de usuário dentro do aplicativo para ecoar as propriedades do objeto de registro do service worker.
Como cancelo o registro de um Service Worker
Esperamos que você não encontre um cenário em que o código do service worker tenha criado um bug de experiência do usuário. Caso o faça, existem algumas coisas que pode fazer para remover ou cancelar o registro de um service worker .
A maioria dos cenários em que você precisa remover um service worker será durante o desenvolvimento do aplicativo. Nesse caso, você pode usar o DevTools para remover ou excluir o service worker.
Se você precisar remover ou excluir um service worker implantado, ficará um pouco mais complicado. Existem maneiras programáticas de tirar você do atolamento.
Leia mais sobre técnicas de remoção.
Cache do Service Worker
A especificação do service worker inclui recursos de cache nativos. Isso substitui o appCache tradicional que causou muitos problemas de gerenciamento desde que foi criado. O armazenamento em cache do Service Worker é muito mais gerenciável.
A API de cache fornece uma camada de persistência que armazena respostas de rede que podem ser consultadas pela solicitação correspondente.
A chave para usar o cache do service worker é o evento’fetch’do service worker. Este evento dispara para cada solicitação de rede, permitindo que você intercepte a solicitação e verifique se a resposta foi armazenada em cache antes de ir para a rede.
Ao acessar ativos no cache local, você pode dispensar solicitações de rede caras. Isso significa que o site pode funcionar quando não há rede, off-line ou conectividade de rede ruim, barras baixas ou falsa conectividade de celular (conhecido como LiFi).
self.addEventListener ("fetch", event=& amp; amp; gt; { event.respondWith (fetchFromCache (evento) .catch (()=& amp; amp; gt; buscar (solicitação) .então (resposta=& amp; amp; gt; addToCache (cacheKey, solicitação, resposta)) .catch (()=& amp; amp; gt; offlineResponse (resourceType, opts)))); });
No exemplo acima, a verificação do código se uma resposta foi armazenada anteriormente em cache. Nesse caso, a resposta em cache é retornada. Caso contrário, a solicitação é repassada à rede.
Quando a solicitação retorna, a resposta é armazenada em cache e retornada à IU.
Se a rede falhar, a lógica volta para uma resposta offline.
Existem muitas partes móveis sendo usadas no código de exemplo. Fornecerei mais detalhes em artigos de acompanhamento.
Como faço para atualizar o cache do meu Service Worker
Um equívoco comum é quando você armazena em cache uma solicitação de rede, ela é armazenada para a eternidade. Este não é o caso. Você tem controle total sobre quando e como o cache é invalidado e atualizado.
Este é um tópico muito complexo e complicado. Acho que posso detalhar pessoalmente cerca de 3 dúzias de estratégias de cache, todas envolvem uma maneira de gerenciar a invalidação de cache ou atualizar o cache.
Acho que a chave para a invalidação é determinar um tempo para invalidar o valor (time to live), um manifesto ou um processo de atualização em segundo plano. Mais tarde, você pode fazer uma solicitação HEAD para ver se uma atualização foi feita no servidor, comparando o valor do cabeçalho atualizado pela última vez com o tempo em que a resposta foi armazenada em cache.
Não existe uma resposta única para cada aplicativo. Você precisará planejar sua estratégia e estar preparado para fazer os ajustes conforme vê como seu aplicativo é usado.
Quais navegadores oferecem suporte aos trabalhadores do serviço?
Todos os navegadores modernos oferecem suporte a service workers , pelo menos cache. Chrome, FireFox e Edge suportam notificações push nativas e Chrome e Edge têm suporte de sincronização em segundo plano.
Isso significa que os principais recursos do PWA estão disponíveis em todos os dispositivos e navegadores. Push e sincronização em segundo plano são aprimoramentos.
Criamos vários Progressive Web Apps que exigiam estratégias sofisticadas de cache offline para permitir que os aplicativos funcionassem offline, mesmo no iOS. Esses aplicativos exigem que todas as solicitações, até mesmo as ações POST, PUT e DELETE sejam armazenadas em cache em uma fila. Fizemos a sincronização desses aplicativos até mesmo no iOS, quando as conexões estavam disponíveis.
Qual é a diferença entre um Service Worker e um Web Worker
Service workers e web workers são ferramentas semelhantes. Ambos executam processos em um thread separado da interface do usuário. A diferença real está no contexto de uso real.
Nenhum dos dois tem acesso ao DOM ou objeto janela. Eles são melhores para tarefas de nível intermediário ou longo, de processo intensivo.
Os web workers só são executados quando uma página da web é aberta e uma tarefa é acionada a partir de um script na página.
Um service worker também pode executar quando uma página é aberta, mas também pode ser acionado por um evento de plataforma como uma notificação push. Uma página da web não precisa ser aberta para um trabalhador de serviço executar.
Os service workers também atuam como proxy entre a rede e a interface do usuário. Se uma página estiver sendo usada (o cenário mais comum), todas as solicitações de rede HTTPS passam pelo service worker, conforme você aprendeu na seção de cache.
A comunicação entre a IU e ambos os trabalhadores é feita usando o método postMessage e o evento de mensagem. Se você fez qualquer programação multi-thread, este modelo é muito familiar.
O que um Service Worker não pode fazer
Os prestadores de serviço não podem acessar o objeto da janela
O objeto de janela é executado no thread de IU, separado do thread de trabalho do serviço. Isso significa que um service worker não pode manipular diretamente os elementos DOM. O service worker e a janela podem se comunicar por meio do método postMessage. Isso permite que as mensagens sejam enviadas e recebidas. Você precisará ter lógica em cada lado para processar as mensagens e acionar diferentes fluxos de trabalho.
Trabalhadores de serviço exigem HTTPS
Como os Service Workers têm muito poder, eles só são ativados se a página for exibida usando HTTPS. Isso garante um nível de segurança para permitir que o service worker faça as coisas para as quais foi projetado.
Sobre HTTP, o service worker seria suscetível a ataques man in the middle. Os desenvolvedores podem trabalhar em localhost, o que nos impede de instalar um certificado TLS local.
Em outras palavras, a resposta para um Service Worker trabalha em HTTP é não. O site ainda será renderizado, mas o service worker não se registra e não é executado.
São apenas assíncronos
Service workers são assíncronos, o que significa que usam e contam com Promises e APIs que usam Promises. Isso significa que APIs síncronas como XHR e localStorage não estão disponíveis para um service worker. Não tema, você pode usar a API Fetch (que substituiu o XHR) e o IndexedDB. A maioria das APIs que não interagem diretamente com o objeto da janela são acessíveis em um service worker.
