Dica prática de Next.js no pessoal
Dica de Next.js nascida em projeto pessoal (Fala Dev/Rocketseat): o tipo de detalhe que docs genéricos não enfatizam.
Resposta direta
Dica de Next.js descoberta em projeto pessoal (Rocketseat/Fala Dev). Se você configurou aí na sua aplicação um cliente de API, né, para fazer requisições para a sua API, e você colocou para o token JWT da sua requisição ser enviado em todas as requisições automaticamente, do front para o back, isso faz com que.
O cenário do bug/dica
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «O cenário do bug/dica». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Fala Dev, eu tô aqui trazendo um vídeo pro YouTube da Rocketseat, onde eu trago uma dica que eu caí e descobri num projeto pessoal mais voltado pra quem desenvolve aplicações com o Next. E esse não é um vídeo que eu vou ficar aqui discutindo sobre os benefícios ou as vantagens e desvantagens de criar ou não um projeto Next. Mas como eu já falei em outros vídeos, se eu tenho um projeto que possui páginas públicas, onde eu quero fazer um bom aproveitamento do sistema de cache, que para mim é uma das grandes vantagens de utilizar um Next em cima de um VIT da vida, sem qualquer outro tipo de framework, sim, para mim o Next continua sendo a melhor opção pela flexibilidade que a gente tem.
Só que, se você já utilizou o Next, sabe, e eu espero que você saiba, caso você seja um heavy user do Next.js, que uma das melhores estratégias do Next, uma das melhores opções de cache que a gente tem no Next, é o Revalidate. O Revalidate do Next permite com que toda vez que eu faço uma requisição do meu front-end para o meu back-end, eu falo que essa requisição vai ser cacheada por um número de segundos. Isso quer dizer que todas as pessoas que fizerem a mesma requisição, que possuem a mesma URL, vão obter os mesmos dados cacheados dentro daquele tanto de segundos que eu configurei.
O que o Next esconde
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «O que o Next esconde». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
E depois desse número de segundos, por exemplo, 30 segundos, a primeira pessoa que fizer uma nova requisição vai salvar esses dados em cache novamente e todas as próximas pessoas que consumirem dentro do próximo intervalo de 30 segundos vão acessar os mesmos dados cacheados. Isso já é um conceito muito antigo que a gente já vem utilizando nas nossas aplicações, que é o famoso incremental static regeneration ou apenas static side generation junto, que são combinados ali pra gente não ter simplesmente estático e pronto. Só que, se você chegou a utilizar o Next num projeto onde você tem autenticação, mais especificamente uma autenticação JWT, uma autenticação onde você envia cabeçalho, um cookie ali em toda a requisição, você sabe que o Next tem um mecanismo de funcionamento que é o seguinte, se você fizer qualquer requisição para o seu back-end, e nesta requisição você incluir informações que estão nos headers, nos cookies da sua aplicação, essas informações fazem com que a sua requisição nunca seja cacheada pelo Next.
Se você configurou aí na sua aplicação um cliente de API, né, para fazer requisições para a sua API, e você colocou para o token JWT da sua requisição ser enviado em todas as requisições automaticamente, do front para o back, isso faz com que você não possa utilizar o mecanismo de cache automático ou o revalidate do Next de maneira alguma na sua aplicação. Ou seja, todas as requisições que são enviadas da sua aplicação a partir do momento que o usuário está logado na sua aplicação não vão ser cacheadas. Só que isso acontecia até hoje, porque hoje eu vou te mostrar uma tática bem legal e eu vou construir junto com você aqui um projeto back-end e um projeto front-end para mostrar uma forma que você pode burlar este funcionamento sem fazer qualquer tipo de gambiarra, só que mantendo a segurança das suas rotas.
Na prática
Dica de Next.js descoberta em projeto pessoal (Rocketseat/Fala Dev).
Como reproduzir
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «Como reproduzir». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Então é uma forma da gente conseguir fazer com que requisições autenticadas sejam cacheadas no front-end ali no Next, de uma maneira sem envolver gambiarras e ser algo que funciona muito bem, inclusive, tá? Olha só, eu vou trazer direto aqui, né, e aqui eu já tô, como eu falei, eu vou codar junto com vocês, mas eu menti um pouco, né, não sou eu totalmente, eu vou vibe codar aqui junto com vocês, porque, né, eu quero desenvolver um projeto, um back-end e um front-end, né, e eu não vou desenvolver tudo isso aqui do zero, né, então eu vou criar um projetinho juntos aqui. Então eu rodei ele diretamente na pasta server e eu vou dar algumas instruções para ele aqui, vou tentar manter as instruções tudo em português para a gente criar juntos aqui, né?
Também use o TypeScript, vamos mandar assim para ele, eu não vou começar, vou deixar ele configurar aí, Eu não vou me preocupar muito Claro, vai ter muita coisa que talvez não vai estar da melhor forma. Tem uma coisa que eu já lembrei aqui, que talvez ele vai fazer da maneira errada, que é, eu não quero que ele instale TSX, eu não quero que ele instale qualquer tipo de. Eu queria que ele estivesse usando o pnpm, porque eu já tinha configurado aqui o package.json com o package-manager-pnpm, mas eu não tinha rodado um init, né?
Quando generalizar
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «Quando generalizar». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Isso aqui é uma coisa que eu faço bastante, às vezes eu vejo que ele tá indo por um caminho errado, já mando ele parar ali mesmo, né, aqui do 1S, que já começo a integrar, né? Crie um hook do Fastify para validar que a requisição está enviando um header x-api-secret que compara com essa env. Porque todo esse ponto da dica que eu estou querendo te trazer do Next conseguir cachear uma requisição, qual que é o ponto?
Lá no Next, se a gente tem uma requisição que é feita para o nosso backend, então imagina que aqui na minha home eu vou fazer uma requisição lá para o backend. Indo lá no next headers, importando aqui cookies e usando esses cookies aqui, de alguma forma que seja, para pegar o cookie de autenticação, o JWT. Só que o next lá na documentação, ele fala, né, toda vez que você importa cookies ou headers de dentro de next headers, todas as requisições feitas dentro daquele arquivo, automaticamente passam a não ser mais cacheadas.
Sinais de que está funcionando
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «Sinais de que está funcionando». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Então, é importante que lá no next, eu crie um arquivo aqui, .env.local, e eu não coloque este next public na frente. E aí eu posso ter aqui acesso ao data, por exemplo, o JSON da requisição, e dentro desse data aqui, eu posso mostrar o resultado aqui do retorno dessa requisição, que logo a gente já vai testar se o cache está funcionando nesse caso. E aí aqui eu posso, por exemplo, passar next, revalidate e botar, por exemplo, a cada 5 segundos que eu quero que ele.
Eu não quero que ele atualize dentro desses 5 segundos, todo mundo que fizer acesso a essa mesma rota vai obter os mesmos dados, né? Então ele gerou aqui o meu servidor, ele criou um hook aqui, tá cheio de erro de tipagem, então aqui, ó run type check and fix errors. Então, enquanto isso ele vai checando aí, ele tem uma rota health e ele tem uma rota de criação de usuários novamente, não pedi pra ele criar rota de criação de usuários, mas ele tem aqui uma rota agora, listagem de usuários que usa o meu hook Auth hook e fala que recebe o header aqui, xAPI secret e devolve aqui a minha lista de usuários que teoricamente eu vou poder cachear.
O que evitar na primeira semana
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «O que evitar na primeira semana». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Eu vou deixar a API terminar de rodar aqui e depois a AI parar de rodar, porque senão eu vou salvar o arquivo em cima do código dela e vai dar erro. Deprecated z.iso.datetime e aí o que eu queria falar aqui, na listagem de usuários deixa eu apagar essa rota de criar usuário aqui eu não quero criar usuário, só quero listar usuários e essa aqui também não, listar um usuário específico não quero isso aqui agora, deixa eu ver vou apagar ela, apagar essa rota aqui e aí, o que eu vou fazer aqui na resposta dessa rota de listagem de usuários eu vou pegar esse array aqui e vou falar que ela vai retornar agora um objeto que vai ter null, que é a data atual que é um z.iso.datetime e o array de usuários Tchau. 53.13 cada vez que eu chamo, 53.16 então cada vez que eu chamo agora a gente vai testar isso aqui lá no nosso front-end, então vou deixar o servidor rodando aqui e agora a gente vai fazer o seguinte, eu vou lá na web tá, e vou rodar aqui pnpm run dev a gente vai aqui no nosso projeto next.js, localhost 3000 E olha só, ele trouxe a lista de usuários.
Só que, como a gente tá fazendo essa requisição pelo server-side, não tem problema em questão de segurança, porque essa requisição, ela nunca vai aparecer aqui nos logs, né, da aba network. Se eu vier aqui e dar um console log, por exemplo, nesse data aqui, ó, a gente pode ver que ele aparece aqui porque eu tô em dev, mas ele aparece aqui, ó, o server, né? Porque ele, na verdade, ele tá aparecendo aqui no terminal, ó, e ele só repassa aqui pro navegador pra uma experiência melhor de desenvolvimento do Next, mas em produção isso aqui não apareceria.
Como explicar isso para o time
Nesta parte do material sobre dica nextjs projeto pessoal, o foco é «Como explicar isso para o time». Em vez de teoria genérica, o raciocínio parte do que acontece quando você executa de verdade.
Mas olha só, eu posso ir dando F5, ó, e ele aparece 54, depois que passa 5 segundos, ó, aí ele vai atualizar. Então, isso aí é uma dica que eu queria trazer para você aí, se você tem um projeto em Next, em produção. Que era um projeto que estava usando Next, que estava usando pouco de cache, porque basicamente todas as rotas eram autenticadas.
Rotas, principalmente, que a gente busca informações que não são específicas pra um usuário, que elas são disponíveis pra todo mundo, imagina, uma listagem de posts, uma listagem de comentários, uma listagem de qualquer coisa que seja que não tenha relação com o usuário específico que tá acessando, e cara, isso trouxe um ganho bem legal, porque a gente pôde trabalhar com o cache do Next aí, usando o Revalidate, que pra mim é sensacional, eu sempre tento manter esse tempo de revalidação baixo, né, então eu boto ali no máximo um minuto, dois minutos, porque a ideia é só você evitar que essa informação seja recarregada todas as vezes que alguém está acessando a tua aplicação, né? Se tiver um milhão de usuários acessando dentro do mesmo minuto, não fazer um milhão de requisições pro teu back-end, fazer uma única requisição, né? Mas você quer que as informações estejam sempre o mais atualizadas possível, então não joga um revalidate de um dia, de dois dias, isso dificilmente vai fazer sentido e dificilmente vai ter ótimos ganhos de performance, né?
Na prática
Próximo passo: escolha uma métrica (taxa de sucesso, tempo, retries ou conversão) e rode um experimento de 7 dias antes de escalar o padrão.