Um trabalho: transformar um arquivo em uma URL cacheável

Um arquivo em que o navegador pode confiar para sempre, ou nunca

Toda folha de estilo e todo script que um navegador carrega precisam de uma URL. Essa URL tem um trabalho difícil: dizer ao navegador por quanto tempo ele pode guardar o arquivo sem perguntar de novo ao servidor. Erre para um lado e todo visitante baixa o mesmo CSS inalterado a cada requisição, desperdiçando banda e tempo. Erre para o outro e um deploy que muda um arquivo deixa os visitantes rodando o CSS ou o JavaScript de ontem, vindo do cache. O asset pipeline do Rails existe para resolver isso, e o Rails 8 resolve com o Propshaft, a gem padrão dele para essa tarefa.

O Gemfile deste app tem gem "propshaft", abaixo do comentário # The modern asset pipeline for Rails [https://github.com/rails/propshaft], e o Gemfile.lock fixa propshaft (1.3.1). O Propshaft substituiu o Sprockets, o asset pipeline que os apps Rails usaram por uma década. Este app nunca usou a gem antiga. Um grep por "sprockets" nos arquivos Ruby, na config YAML, no Gemfile e no lockfile não devolve nada. Também não existe app/assets/config/manifest.js, o arquivo em que todo app com Sprockets listava os pontos de entrada. Este app não tem o diretório app/assets/config.

O que "fingerprinting" significa

Os dois pipelines usam um nome de arquivo derivado do conteúdo. Em vez de tailwind.css, o navegador pede algo como tailwind-fe18c29a.css: um hash do conteúdo do arquivo, inserido logo antes da extensão. Mude um byte do CSS e o hash muda, gerando uma URL nova. Um navegador mandado guardar tailwind-fe18c29a.css em cache para sempre pode fazer isso com segurança, porque quando o conteúdo muda, a URL muda junto. Uma URL com o nome do próprio conteúdo não tem como apontar para conteúdo desatualizado. Essa ideia, "a URL é a impressão digital", é o mecanismo que este curso checa nas próximas seis aulas. A checagem é feita contra a gem propshaft-1.3.1 instalada neste app, o diretório app/assets dele e o servidor de desenvolvimento.

O que este curso cobre

A aula 2 mostra como o Propshaft monta o load path e o que este app coloca nele. A aula 3 explica por que o desenvolvimento não precisa de uma etapa separada de compilação, checado com requisições a este app em desenvolvimento. A aula 4 mostra como as referências url() dentro do CSS são reescritas, e como o Propshaft e o importmap-rails dividem o trabalho de servir JavaScript. A aula 5 lê as chamadas stylesheet_link_tag dos layouts deste app e os dois jeitos de o Propshaft resolver um caminho lógico para uma URL. A aula 6 trata do deploy, a partir do Dockerfile e da config de produção deste app. A aula 7 segue um arquivo da origem até a URL, com um desafio construído a partir do código de fingerprinting do Propshaft.