Service workers e a API Cache Storage

Jeff Posnick

Você está preso em uma luta pela confiabilidade da rede. O cache HTTP do navegador é a primeira linha de defesa. No entanto, como você aprendeu, ele só é eficaz ao carregar URLs com versões anteriores que você já visitou. Por si só, o cache HTTP não é suficiente.

Felizmente, duas ferramentas mais recentes estão disponíveis para mudar a situação a seu favor: os service workers e a API Cache Storage. Como são frequentemente usados juntos, vale a pena aprender sobre os dois ao mesmo tempo.

Service workers

Um service worker é integrado ao navegador e controlado por um pouco de código JavaScript extra, que você é responsável por criar. Você o implanta junto com os outros arquivos que compõem o aplicativo da Web real.

Um service worker tem alguns poderes especiais. Entre outras funções, ele espera pacientemente que o app da Web faça uma solicitação de saída e, em seguida, entra em ação por meio da interceptação dela. Você decide o que o service worker faz com essa solicitação interceptada.

Para algumas solicitações, a melhor providência pode ser apenas permitir que ela continue na rede, como o que aconteceria se não houvesse um service worker.

Para outras solicitações, no entanto, é possível aproveitar algo mais flexível do que o cache HTTP do navegador e retornar uma resposta rápida e confiável sem se preocupar com a rede. Isso envolve usar a outra peça do quebra-cabeça: a API Cache Storage.

A API Cache Storage

Compatibilidade com navegadores

  • 43
  • 16
  • 41
  • 11.1

Origem

A API Cache Storage abre uma nova gama de possibilidades, oferecendo aos desenvolvedores controle total sobre o conteúdo do cache. Em vez de depender de uma combinação de cabeçalhos HTTP e da heuristics integrada do navegador, a API Cache Storage expõe uma abordagem de armazenamento em cache orientada por código. A API Cache Storage é particularmente útil quando chamada a partir do JavaScript do service worker.

Espera... já tem outro cache para você pensar?

Você provavelmente está se perguntando: "Ainda preciso configurar meus cabeçalhos HTTP?" e "O que posso fazer com esse novo cache que não era possível com o cache HTTP?". Não se preocupe, essas são reações naturais.

Ainda é recomendável configurar os cabeçalhos Cache-Control no servidor da Web, mesmo quando você sabe que está usando a API Cache Storage. Geralmente, é possível configurar Cache-Control: no-cache para URLs sem versão e/ou Cache-Control: max-age=31536000 para URLs que contêm informações de controle de versão, como hashes.

Ao preencher o cache da API Cache Storage, o navegador por padrão verifica as entradas existentes no cache HTTP e as usa, se encontradas. Se você adicionar URLs com controle de versão ao cache da API Cache Storage, o navegador vai evitar outra solicitação de rede. Por outro lado, se você usar cabeçalhos Cache-Control mal configurados, como especificar um ciclo de vida de cache de longa duração para um URL sem versão, poderá piorar as coisas adicionando esse conteúdo obsoleto à API Cache Storage. A classificação do comportamento do cache HTTP é um pré-requisito para usar efetivamente a API Cache Storage.

Quanto ao que agora é possível com essa nova API, a resposta é: muito. Alguns usos comuns que seriam difíceis ou impossíveis apenas com o cache HTTP incluem:

  • Use uma abordagem de "atualização em segundo plano" para conteúdo em cache, conhecida como desatualizado ao revalidar.
  • Imponha um limite para o número máximo de recursos a serem armazenados em cache e implemente uma política de expiração personalizada para remover itens quando esse limite for atingido.
  • Compare respostas de rede atualizadas e armazenadas em cache para ver se algo mudou e permita que o usuário atualize o conteúdo (com um botão, por exemplo) quando os dados realmente foram atualizados.

Confira A Cache API: um guia rápido para saber mais.

Porcas e parafusos da API

Há algumas coisas para ter em mente sobre o design da API:

  • Os objetos Request são usados como as chaves exclusivas ao ler e gravar nesses caches. Por conveniência, você pode transmitir uma string de URL como 'https://example.com/index.html' como a chave em vez de um objeto Request real, e a API vai processar isso automaticamente para você.
  • Objetos Response são usados como os valores nesses caches.
  • O cabeçalho Cache-Control em uma determinada Response é efetivamente ignorado ao armazenar dados em cache. Não há verificações automáticas de validade ou atualização integradas e, depois de armazenar um item no cache, ele persistirá até que seu código o remova explicitamente. Existem bibliotecas que simplificam a manutenção do cache em seu nome. Eles serão abordados mais adiante nesta série.
  • Ao contrário das APIs síncronas mais antigas, como LocalStorage, todas as operações da API Cache Storage são assíncronas.

Um desvio rápido: promessas e async/await

Os service workers e a API Cache Storage usam conceitos de programação assíncrona. Em especial, elas dependem muito de promessas para representar o resultado futuro de operações assíncronas. Conheça as promessas e a sintaxe relacionada async/await antes de começar.

Ainda não implante este código

Embora eles forneçam uma base importante e possam ser usados no estado em que se encontram, os service workers e a API Cache Storage são elementos básicos de nível mais baixo, com vários casos extremos e "pegadinhas". Há algumas ferramentas de nível superior que podem ajudar a suavizar as partes difíceis dessas APIs e fornecem tudo o que você precisa para criar um service worker pronto para produção. O próximo guia aborda uma dessas ferramentas: o Workbox.