Porque escolhemos Next.js para projetos headless
Renderizacao no servidor, rotas de ficheiro e uma fronteira clara com o CMS. Explicamos a escolha e o que ficou fora dela.
- Development
- Alisson Machado
- 1 min read
O que atravessa a fronteira
Num setup headless, o CMS deixa de decidir como o conteudo aparece. O que ele decide e o contrato: os campos que existem e o formato deles.
O Next.js entra porque separa bem essa fronteira — a camada de dominio nao conhece WordPress, e a camada de infraestrutura nao decide regra de negocio.
A troca tem custo: o que muda no CMS so aparece no site depois de um novo pedido, e por isso a invalidacao por evento importa tanto quanto a escolha da framework.
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.