Um site Next.js estático no Cloudflare Workers

Este site é feito com Next.js e React, mas em lado nenhum corre um servidor Node.js. Cada página pública é gerada como HTML estático no build e servida a partir da edge da Cloudflare. Um pequeno Worker trata das poucas coisas que precisam mesmo de servidor. Eis porquê e como as peças encaixam.

#Estático primeiro

Quase tudo num site de portefólio e demos é conteúdo estável: descrições de demos, artigos, estudos de caso, páginas de ferramentas. Nada disso muda de visitante para visitante, por isso gerá-lo a cada pedido acrescentaria atraso e custo sem benefício.

Com output: "export", o Next.js gera cada rota — incluindo as dinâmicas como /demos/[slug], enumeradas com generateStaticParams — como ficheiros HTML simples. O resultado:

• Primeira apresentação rápida — o HTML chega completo, sem tempo de renderização no servidor.
• JavaScript mínimo — os componentes de servidor não enviam código ao cliente; só as peças interativas são ativadas (filtros, calculadoras, o visualizador de demos).
• Custo quase zero — os ficheiros estáticos na Cloudflare são servidos a partir da cache.
• Falhas simples — não há servidor de aplicação que possa cair.

#Onde ainda é preciso um servidor

Três coisas não podem ser estáticas:

1. A área de administração tem de ser protegida antes de ser enviado qualquer conteúdo.
2. As estatísticas e os relatórios de erros precisam de um endpoint que os receba.
3. As funções comerciais têm de ser recusadas no servidor, não apenas escondidas.

Um Worker fica à frente dos ficheiros estáticos apenas para /admin e /api/*. Verifica um cookie de sessão assinado nas rotas de administração, limita as tentativas de acesso, regista o número de visualizações num Durable Object sem cookies nem endereços IP e responde 403 a qualquer endpoint comercial, a não ser que uma flag esteja explicitamente definida no servidor. Todos os outros pedidos vão diretamente para os ficheiros estáticos.

#Os rascunhos nunca chegam a ficar online

O conteúdo tem um estado: rascunho, pré-visualização, publicado ou arquivado. O build só gera páginas para os publicados e as pré-visualizações; as pré-visualizações têm noindex e não aparecem nas listas nem no mapa do site. Os rascunhos nunca se tornam ficheiros, por isso não há nada que possa fugir.

#Cabeçalhos de segurança num só ficheiro

Os ficheiros estáticos no Workers suportam um ficheiro _headers, por isso os cabeçalhos de segurança declaram-se uma só vez: uma política de segurança de conteúdo rigorosa que só permite em frames a origem do gerador de demos, X-Content-Type-Options, uma política de referrer prudente e uma política de permissões que desativa os sensores que o site não usa.

#404 corretos

A configuração dos ficheiros estáticos serve o 404.html gerado com um código 404 real para os caminhos desconhecidos, por isso os motores de pesquisa não indexam páginas soft-404.

#Compromissos

• Sem personalização por pedido. Tudo o que é dinâmico tem de correr no browser ou no Worker.
• Publicar exige novo build. As alterações de conteúdo exigem build e implementação. Para um site que muda algumas vezes por semana, é uma vantagem: cada alteração é verificada e versionada.
• Sem otimização de imagens incluída. As capturas de ecrã são convertidas em WebP na criação e servidas em tamanhos fixos.

Para um site de demonstração, os compromissos valem largamente a pena: o resultado é rápido, barato, seguro de origem e fácil de perceber.