Service workers e a API Cache Storage

Jeff Posnick

Você está em uma luta pela confiabilidade da rede. O cache HTTP do navegador é sua primeira linha de defesa, mas, como você aprendeu, ele só é realmente eficaz ao carregar URLs com controle de versão que você já acessou. Por si só, o cache HTTP não é suficiente.

Felizmente, duas ferramentas mais recentes estão disponíveis para ajudar a mudar a situação a seu favor: service workers e a API Storage de Cache. Como eles são usados juntos com tanta frequência, 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ê precisa criar. Ele é implantado com os outros arquivos que compõem o aplicativo da Web.

Um service worker tem alguns poderes especiais. Entre outras funções, ele espera pacientemente que seu app da Web faça uma solicitação de saída e, em seguida, entra em ação interceptando-a. O que o service worker faz com essa solicitação interceptada depende de você.

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

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

API Cache Storage

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

A API Cache Storage abre uma nova gama de possibilidades, aos desenvolvedores controle total sobre o conteúdo do cache. Em vez de depender de uma combinação de cabeçalhos HTTP e das heurísticas integradas do navegador, a API Cache Storage expõe uma abordagem de armazenamento em cache baseada em código. A API Cache Storage é particularmente útil quando chamada pelo JavaScript do service worker.

Espera… tem outro cache para pensar agora?

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. Normalmente, basta definir Cache-Control: no-cache para URLs sem controle de 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 Storage Cache, o navegador verifica por padrão se há entradas 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 uma solicitação de rede extra. Por outro lado, se você estiver usando cabeçalhos Cache-Control configurados incorretamente, 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 desatualizado à API Cache Storage. Organizar o comportamento do cache HTTP é um pré-requisito para usar a API Storage de maneira eficaz.

Quanto ao que agora é possível com essa nova API, a resposta é: muita coisa. 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 o conteúdo armazenado em cache, conhecida como stale-while-revalidate.
  • Imponha um limite máximo de recursos para armazenar em cache e implemente uma política de validade personalizada para remover itens quando esse limite for atingido.
  • Compare as respostas de rede novas 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 forem atualizados.

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

Noções básicas da API

Há alguns pontos a serem considerados sobre o design da API:

  • Os objetos Request são usados como chaves exclusivas ao ler e gravar nesses caches. Para facilitar, é possível 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ê.
  • Os objetos Response são usados como os valores nesses caches.
  • O cabeçalho Cache-Control em um determinado Response é ignorado ao armazenar dados em cache. Não há verificações automáticas e integradas de validade ou atualização. Depois que você armazena um item no cache, ele persiste até que seu código o remova explicitamente. Há bibliotecas para simplificar 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 Storage usam conceitos de programação assíncrona. Em particular, eles dependem muito de promessas para representar o resultado futuro de operações assíncronas. Antes de começar, familiarize-se com as promessas e a sintaxe relacionada async/await.

Não implante esse código… ainda

Embora forneçam uma base importante e possam ser usados como estão, os service workers e a API Cache Storage são, na verdade, componentes de nível inferior, com vários casos extremos e "pegadinhas". Existem algumas ferramentas de nível superior que podem ajudar a suavizar as partes difíceis dessas APIs e fornecer tudo o que você precisa para criar um service worker pronto para produção. O próximo guia aborda uma dessas ferramentas: Workbox.