Como autenticar e cachear requisições
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
Como autenticar e cachear requisições. 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.
O dilema do cache em rotas autenticadas
App Next com páginas públicas e privadas precisa de cache pra não gastar fortuna em servidor.
Estratégia revalidate resolve isso... até você colocar JWT. Aí Next detecta
autenticação e mata o cache completamente. Site fica lento, servidor sobrecarregado, custo explode.
Atenção
Cookie, header customizado, sessão de usuário - qualquer um desses invalida cache server-side
do Next. Performance cai e às vezes o time nem percebe até a conta do servidor chegar.
Por que o Next.js dificulta caching com JWT?
Next foi feito pensando em segurança. Detectou header customizado ou cookie do next/headers ? Gera tudo dinâmico, desabilita cache. Intenção é boa -
evitar vazar dados privados. Mas fode com performance. Rota com JWT Authorization nunca
usa SSR cache ou revalidate .
Info
Limitação existe pra evitar vazar dados privados por cache mal feito.
Roubo de sessão e leak de info confidencial são riscos reais quando você caga na implementação.
Oportunidade: cache com API Key por rota pública
Nem toda rota precisa saber quem é o usuário. Listagem geral, conteúdo público - isso pode
ser igual pra todo mundo. Nesses casos, API Key fixa resolve: autentica
sem vincular ao usuário. Revalidate fica ativo, cache funciona, resposta
instantânea.
Atenção
NUNCA coloca API Key em next public ou client-side. Segredo fica só no
backend e em variável de ambiente privada do server. Exposição = desastre.
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
Separa rotas que precisam de contexto do usuário das que podem usar só API Key. Vamos montar
micro backend em Fastify conectado no Next, com TypeScript e Zod pra manter tipagem forte.
Atenção
Usa PNPM ou fica num gerenciador só. Misturar npm, yarn e pnpm gera
diferença de lock e quebra instalação.
Passo a Passo: Configurando o servidor Fastify
- Passo 1: Inicie o projeto na pasta server e
instale Fastify , Zod e TypeScript na última versão estável, preferencialmente via
PNPM. - Passo 2: Configure o TypeScript com suporte a Experimental Strip Types e modos de desenvolvimento via scripts
no package.json. - Passo 3: Crie um arquivo .env contendo apenas
uma variável API_SECRET com valor aleatório. - Passo 4: Implemente um hook Fastify que
verifica se o header x-api-secret bate com o valor da env, e
bloqueia requisições não autenticadas. - Passo 5: Crie uma rota para retornar uma lista de usuários
fictícios autenticada apenas por API Key, sem referência a JWT.
Conectando Next.js com a rota protegida via API Key
No front, consome a rota dentro de Server Components ou getServerSideProps usando variável ambiente privada (SEM
prefixo next public). Requisição vai com header x-api-secret e a chave
segura - Next cacheia automático.
Dica de segurança
API Key nunca vai pro cliente. NUNCA usa process.env.NEXT_PUBLIC_* pra
chave sensível. Isso é suicídio.
Como controlar o revalidate e obter ultra performance
Define revalidate com ou getStaticProps e o cache compartilha pra todo mundo, atualizando a cada N
segundos. Segredo: requisição não pode depender de contexto do usuário (sem JWT),
só header estático. Aí resposta fica instantânea pra todos.
Limitações e cuidados extras da estratégia
Nem tudo usa API Key. Endpoint com dado sensível do usuário precisa de JWT via header ou
cookie - e aí cache morre mesmo. Avalia caso a caso: precisa personalizar? Precisa proteger
dado individual? Então JWT. Senão, API Key.
Erro comum
Expôs API Key no client? Qualquer um copia, reutiliza e vaza seus dados "protegidos".
Presta atenção nesse ponto ou você se fode feio.
Ferramentas e dependências recomendadas
Boas práticas para ambientes reais
Separa claro: rotas públicas (API Key, cacheia) e privadas (JWT, sem cache). Loga falha
de autenticação. Rotaciona API Key regularmente. Segredos em variável de ambiente, nunca
no Git. Valida endpoint em staging antes de subir pra produção.
Importante
Cache não é proteção. Implementa autenticação multi-nível e monitora acesso suspeito.
Quando não usar esta abordagem
Não usa essa estratégia em endpoint com informação individualizada, dado crítico ou que
precisa rastrear sessão. Só rota realmente pública mas que precisa de legitimidade de
acesso serve pra API Key cacheada.
Checklist de Implementação
Checklist de Implementação
- Separou rotas públicas e privadas no backend
- Implementou header x-api-secret protegido por variável de ambiente
- Consumiu endpoints via Server Component/SSR e não client-side
- Testou revalidate/local e em deploy cloud
- Garantiu que variáveis sigilosas não estão públicas nem versionadas
- Rotas privadas continuam JWT-only
- Validou logs e possíveis falhas de autenticaçã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.
Perguntas frequentes
Por que o Next.js dificulta caching com JWT?
Next foi feito pensando em segurança. Detectou header customizado ou cookie do next/headers ? Gera tudo dinâmico, desabilita cache. Intenção é boa - evitar vazar dados privados. Mas fode com performance. Rota com JWT Authorization nunca usa SSR cache ou revalidate .
Como implementar do zero: backend Fastify + Next.js
Separa rotas que precisam de contexto do usuário das que podem usar só API Key. Vamos montar micro backend em Fastify conectado no Next, com TypeScript e Zod pra manter tipagem forte.
Como controlar o revalidate e obter ultra performance
Define revalidate com ou getStaticProps e o cache compartilha pra todo mundo, atualizando a cada N segundos. Segredo: requisição não pode depender de contexto do usuário (sem JWT), só header estático. Aí resposta fica instantânea pra todos.
Quando não usar esta abordagem
Não usa essa estratégia em endpoint com informação individualizada, dado crítico ou que precisa rastrear sessão. Só rota realmente pública mas que precisa de legitimidade de acesso serve pra API Key cacheada.