Como autenticar e cachear requisições com Next.js e Fastify sem perder performance
Aprenda a combinar autenticação API Key e JWT para obter caching eficiente em aplicações Next, melhorando experiência e performance sem abrir mão da segurança.
Por que isso é importante
Cachear rotas autenticadas em aplicações Next.js é um dos maiores desafios de performance moderna. Errar na estratégia pode dobrar custos, perder SEO e degradar a experiência do usuário. Aqui você aprende como evitar armadilhas famosas do uso de JWT e aproveitar todo o potencial de caching, mesmo em rotas protegidas, unindo alta velocidade e segurança no front e backend.
O dilema do cache em rotas autenticadas
Ao desenvolver aplicações Next.js com páginas públicas e privadas, surge a necessidade de garantir respostas rápidas e econômicas através do cache, especialmente usando a estratégia revalidate. Porém, quando há autenticação do tipo JWT via headers ou cookies, o Next.js impede totalmente o uso do cache nessas rotas – o que pode prejudicar drasticamente a escalabilidade e velocidade do site.
⚠️Atenção
Sempre que uma requisição envolver cookies, headers personalizados ou informações ligadas à sessão do usuário, o cache server-side do Next é invalidado. Isso pode gerar desempenho ruim sem que o time note.
Por que o Next.js dificulta caching com JWT?
O comportamento padrão do Next.js foi desenhado para garantir a segurança e integridade dos dados do usuário. Ao detectar headers customizados ou cookies vindos do next/headers, qualquer resposta passa a ser gerada de forma dinâmica, desabilitando cache para aquela rota. Assim, páginas que dependem de JWT Authorization nunca aproveitam SSR cache ou revalidate.
ℹ️Info
Essa limitação é focada em evitar exposição de dados privados através de respostas cacheadas indevidamente. Roubo de sessão e leaking de informações confidenciais são riscos reais em implementações imprudentes.
Oportunidade: cache com API Key por rota pública
Em muitos casos não faz sentido vincular cada consulta a um usuário: listagens gerais ou conteúdo público podem ser servidos a vários clientes sem informações sensíveis. Para essas rotas, utilizar uma API Key fixa é uma alternativa interessante, pois permite autenticação sem acoplar a resposta ao usuário. Assim, mantemos o revalidate ativo e o cache gerando respostas instantâneas.
⚠️Atenção
Jamais exponha a chave de API em variáveis next public ou diretamente no client-side. O segredo deve residir apenas no backend e nos files de variáveis ambiente privadas do server.
Comparando: JWT vs API Key para rotas cacheáveis
Autenticação JWT
Tokens atrelados ao usuário, enviados por cookie ou header, contendo claims pessoais.
Prós
- Permite granularidade por usuário
- Segurança nativa em rotas privadas
Contras
- Desabilita completamente cache Next
- Impede resposta estática e revalidação
API Key Header
Chave fixa compartilhada apenas entre Next Server e backend para autenticar rotas públicas, sem amarrar usuário.
Prós
- Permite cache eficiente do Next
- Ideal para dados públicos ou semi-públicos
Contras
- Não oferece payload individual
- Não recomendado para recursos sensíveis
Como implementar do zero: backend Fastify + Next.js
O fluxo ideal é separar rotas que realmente precisam do contexto do usuário daquelas que podem ser autenticadas apenas com uma API Key. Vamos estruturar um micro backend em Fastify e conectar a um projeto Next, sem abrir mão de tipagem (TypeScript e Zod).
⚠️Atenção
Use sempre PNPM ou outro gerenciador consistente durante toda a configuração de pacotes para evitar diferenças de lock e instalação.
Passo a Passo: Configurando o servidor Fastify
Conectando Next.js com a rota protegida via API Key
No front-end, recomendamos consumir esta rota dentro de Server Components ou getServerSideProps, usando variável ambiente privada (SEM prefixo next public) para inserir a API Key de forma segura. A requisição inclui o header x-api-secret com a chave corretamente posicionada – permitindo cache automático pelo Next.
✅Dica de segurança
Garanta que as variáveis API Key nunca passem para o lado do cliente. Nunca use process.env.NEXT_PUBLIC_* para chaves sensíveis.
Como controlar o revalidate e obter ultra performance
Ao definir a opção revalidate – seja com fetch(..., { next: { revalidate: N }}) ou getStaticProps –, você garante cache compartilhado entre vários acessos, atualizando a cada N segundos. O segredo é garantir que a requisição não dependa do contexto do usuário – ou seja, sem JWT – e use apenas headers estáticos, permitindo resposta praticamente instantânea para todos por um ciclo de tempo.
Limitações e cuidados extras da estratégia
Nem todas as rotas podem ser autenticadas por API Key: endpoints que retornam dados sensíveis do usuário continuam exigindo JWT via headers ou cookies, mantendo o cache desativado. Avalie cada endpoint conforme a necessidade de personalização e exposição de dados.
❌Erro comum
Caso exponha sua API Key ou use métodos client-side para consumir endpoints privados, qualquer usuário será capaz de copiar, reutilizar e até “vazar” dados supostamente protegidos. Preste absoluta atenção nesse ponto.
Ferramentas e dependências recomendadas
Boas práticas para ambientes reais
Separe claramente rotas públicas (API Key, cacheável) de privadas (JWT, sem cache). Implemente logging para falhas de autenticação, rotate regularmente as chaves de API e use variáveis de ambiente para todos os segredos – sempre fora do versionamento. Automatize validação dos endpoints em ambiente de staging antes de aplicar em produção.
ℹ️Importante
Não confie apenas no cache para proteção de endpoints. Invista em autenticação multi-nível e monitoramento de acessos suspeitos.
Quando não usar esta abordagem
Não aplique esta estratégia em endpoints que processem ou devolvam informações individualizadas, dados críticos ou recursos que necessitem rastreamento de sessão. Somente rotas verdadeiramente públicas, porém que exigem alguma legitimidade de acesso, são aptas para API Key cacheada.
Checklist de Implementação
Checklist de Implementação
✅Transforme sua carreira
E foi EXATAMENTE por isso que eu criei um curso de Node.js e React chamado CrazyStack. A minha maior necessidade no início da carreira era alguém que me ensinasse um projeto prático onde eu pudesse não só desenvolver minhas habilidades de dev como também lançar algo pronto para entrar no ar no dia seguinte.
Sabe qual era minha maior frustração? Aplicar conhecimentos teóricos em projetos práticos e reais, mas não encontrar ninguém que me ensinasse COMO fazer isso na prática! Era exatamente a mesma frustração que você deve sentir: acumular informação sem saber como implementar na prática.
Assim como você precisa de estratégias claras e implementação prática para ter sucesso, todo desenvolvedor precisa de um projeto estruturado para sair do teórico e partir para a execução. É como ter todas as peças do quebra-cabeça mas não saber como montá-las - você pode ter conhecimento técnico, mas sem um projeto completo, fica difícil transformar esse conhecimento em resultados concretos.
No CrazyStack, você constrói um SaaS completo do zero - backend robusto em Node.js, frontend moderno em React, autenticação, pagamentos, deploy, tudo funcionando. É o projeto que eu queria ter quando comecei: algo que você termina e pode colocar no ar no mesmo dia, começar a validar com usuários reais e até monetizar.