React
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.
Next.jsFastify
Carregando
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.
Como o Next.js 16 mudou o jogo da performance web ao permitir cache e pré-renderização parcial em partes...
Como cachear funções no Next.js com controle, flexibilidade e ganhos reais de performance. Aprenda a variar...
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.
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.
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.
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 .
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.
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.
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.
Tokens atrelados ao usuário, enviados por cookie ou header, contendo claims pessoais.
Chave fixa compartilhada apenas entre Next Server e backend para autenticar rotas públicas, sem amarrar usuário.
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.
Usa PNPM ou fica num gerenciador só. Misturar npm, yarn e pnpm gera diferença de lock e quebra instalação.
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.
API Key nunca vai pro cliente. NUNCA usa process.env.NEXT_PUBLIC_* pra chave sensível. Isso é suicídio.
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.
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.
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.
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.
Cache não é proteção. Implementa autenticação multi-nível e monitora acesso suspeito.
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.
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.