Cache e invalidacao por evento num site headless

Etiquetar antes de guardar

Um tempo de expiracao fixo escolhe entre servir depressa e servir certo, e escolhe mal nos dois extremos.

A alternativa e etiquetar cada resposta pelo que a compoe, e deixar o CMS avisar quando algo com essa etiqueta muda.

A partir dai, publicar deixa de exigir um novo build e passa a ser um pedido que invalida o que ficou velho.

A fronteira antes da ferramenta

A escolha da stack e a decisao mais visivel e raramente a mais importante. O que decide se um projeto envelhece bem e onde estao as fronteiras: o que sabe de que, e o que acontece quando uma das pontas muda.

Uma camada de dominio que nao conhece o CMS pode trocar de CMS. Uma que o conhece nao pode — e a diferenca nao se ve no primeiro mes, ve-se no segundo ano.

Por isso o teste que fazemos a qualquer desenho e sempre o mesmo: se amanha isto mudar, quantos ficheiros tenho de abrir?

O que o teste automatico deve provar

Um teste que repete a implementacao nao prova nada: falha quando o codigo muda e passa quando o comportamento parte. Custa a escrever, custa a manter, e da uma confianca que nao existe.

O que vale a pena fixar sao invariantes — coisas que tem de ser verdade seja qual for a implementacao. Uma pagina fora de limites cai na ultima que existe. Um filtro desconhecido nao rebenta. Um bloco oferecido no editor tem renderer.

Escritos assim, os testes sobrevivem a refactorizacoes e continuam a apanhar o que interessa.