Service workers e a API Cache Storage

Jeff Posnick

Você está lutando 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 versões que você já visitou. 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 Cache Storage. Como eles são usados com frequência, vale a pena aprender sobre os dois ao mesmo tempo.

Service workers

Um worker de serviço é integrado ao navegador e controlado por um pouco de código JavaScript extra que você é responsável por criar. Implante esse arquivo com os outros arquivos que compõem seu aplicativo da Web.

Um service worker tem alguns poderes especiais. Entre outras tarefas, ele espera pacientemente que o app da Web faça uma solicitação de saída e, em seguida, entra em ação ao interceptá-la. O que o service worker faz com essa solicitação interceptada é sua decisão.

Para algumas solicitações, a melhor ação pode ser permitir que a solicitação continue na rede, assim como aconteceria se não houvesse nenhum worker de serviço.

No entanto, para outras solicitações, você pode aproveitar algo mais flexível do que o cache HTTP do navegador e retornar uma resposta confiávelmente rápida sem se preocupar com a rede. Isso envolve usar a outra parte do quebra-cabeça: a API Cache Storage.

A API Cache Storage

A API Cache Storage abre uma gama totalmente nova 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 as heurísticas integradas do navegador, a API Cache Storage expõe uma abordagem orientada a código para o armazenamento em cache. A API Cache Storage é especialmente útil quando chamada pelo JavaScript do seu worker de serviço.

Peraí, há 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. Geralmente, é possível definir Cache-Control: no-cache para URLs sem versão e/ou Cache-Control: max-age=31536000 para URLs que contêm informações de versionamento, como hashes.

Ao preencher o cache da API Cache Storage, o navegador verifica por padrão as entradas existentes no cache HTTP e as usa se encontradas. Se você adicionar URLs com versões ao cache da API Storage, o navegador vai evitar uma solicitação de rede extra. O outro lado disso é que, se você estiver usando cabeçalhos Cache-Control configurados incorretamente, como especificar um cache de longa duração para um URL sem versão, você pode piorar as coisas adicionando esse conteúdo desatualizado à API Cache Storage. Classificar o comportamento do cache HTTP é um pré-requisito para usar a API Cache Storage de maneira eficaz.

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

• Use uma abordagem de "atualização em segundo plano" para conteúdo armazenado em cache, conhecida como "revalidação enquanto inválido".
• Estabeleça um limite máximo para o número de recursos em cache e implemente uma política de expiração personalizada para remover itens quando esse limite for atingido.
• Compare as respostas da rede armazenadas em cache e as novas para saber 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.

Detalhes da API

É importante considerar alguns pontos sobre o design da API:

• Os objetos Request são usados como chaves exclusivas ao ler e gravar nesses caches. Para sua conveniência, é 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 integradas de validade ou de frescor. Depois que você armazena um item no cache, ele permanece até que o código o remova explicitamente. Há bibliotecas para simplificar a manutenção do cache. 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 workers de serviço e a API Cache Storage usam conceitos de programação assíncrona. Especificamente, 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 async/await relacionada.

Não implante esse código ainda

Embora eles forneçam uma base importante e possam ser usados como estão, os workers de serviço e a API Cache Storage são blocos de construção de nível inferior, com vários casos extremos e "gotchas". Há algumas ferramentas de nível mais alto que podem ajudar a resolver os problemas 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.