Como Fazer Uma API (o jeito mais fácil e moderno que eu já vi)
Como Fazer Uma API (o jeito mais fácil e moderno que eu já
196.377 visualizações • 18 de jan. de 2021 • Aprender a programar uma API Rest (REST API) utilizando Variáveis de Ambiente (Environment Variables) é uma habilidade extremamente profissional que um programador ou programadora deve ter quando se trata de Programação Web (Web Development), principalmente quando atreladas a estratégias de cache avançadas como o "stale while revalidate" (e que também vemos como programar dentro deste vídeo). Então se você tem dúvidas sobre "O que é API", "O que é API REST", "O que é um Endpoint", ou "Como usar o process.env para ler a Variavel de Ambiente" e está a procura de um tutorial backend que ensine como usar o Next.js para hospedar a sua API na Vercel de uma forma profissional, este vai ser o melhor vídeo para entrar nesse assunto. Inclusive dentro das "Next Js API Routes" nós vamos ver os conceitos de "Request Response" que é o que move o Desenvolvimento Web nos dias de hoje, incluindo como fazer respostas utilizando JSON. ✅ 𝗟𝗜𝗡𝗞𝗦 𝗖𝗜𝗧𝗔𝗗𝗢𝗦 𝗡𝗢 𝗩Í𝗗𝗘𝗢 ▸ Newsletter sobre Tecnologia: https://filipedeschamps.com.br/newsle... ✅ 𝗢𝗟𝗛𝗔 𝗤𝗨𝗘 𝗠𝗔𝗦𝗦𝗔! ▸ Se essas conversas aqui estão fazendo você perceber coisas diferentes no seu código, ou na sua profissão de desenvolvedor, considera se tornar um Membro da Turma. É muito massa porque dá pra ter uma conversa muito mais próxima e discutir coisas bem diferentes e super importantes do nosso dia a dia: https://www.youtube.com/FilipeDescham... ✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟 ▸ Preguiça: Descobri Como Consertar o Meu Maior Problema https://youtu.be/rHANBi7E2cI ▸ 3 Técnicas Que Eu Uso Para Aprender a Programar Qualquer Coisa https://youtu.be/ZtMzB5CoekE ▸ S.O.L.I.D. fica FÁCIL com Essas Ilustrações https://youtu.be/6SfrO3D4dHM ▸ Eu fiz um dos melhores cursos de Programação do Mundo! https://youtu.be/elIl48sZ3rA ▸ Desafio: 10 projetos rápidos para treinar Programação e conseguir um Emprego https://youtu.be/fYR9L2ZmodM Mostrar menos Mostrar mais
Neste vídeo, eu vou mostrar a forma mais fácil que existe atualmente de como fazer uma API, como colocar em produção num domínio .com.br de verdade, como escalá-la infinitamente, onde você vai se ferrar tentando escalá-la infinitamente, como armazenar segredos, como senhas ou token de acesso de uma forma segura, profissional para te libertar a construir suas próprias APIs REST para serem usadas em qualquer site, aplicativo, ou sistema que você queira integrar para você literalmente conseguir
construir o que quiser daqui para frente, principalmente aquela ideia que só você teve e que já está na hora de sair do papel. E apesar que alguns desses tópicos possam parecer um pouco avançados, do jeito que eu vou mostrar aqui vai ficar muito fácil e realmente qualquer pessoa vai conseguir programar a sua própria API e hospedá-la de graça. E está tudo tão fácil que a explicação que eu vou incrementar ao redor do código, vai ser muito maior do que o próprio código em si. E hoje ain da quando
fizermos o primeiro deploy juntos, você vai pensar: "Tá, mas é só isso de código para ter uma API no ar? Eu fiquei me enrolando todo esse tempo só para isso?" E sim, é pouco código e é sensacional. Este vídeo aqui faz parte de uma playlist de desenvolvimento web, mas você não precisa assistir os outros vídeos para entender este aqui. Até porque nos outros vídeos, eu explico como criar páginas estáticas e elas têm uma limitação fundamental quando comparadas à flexibilidade de uma
API. Necessariamente para que as páginas estáticas consigam atingir o seu nível insano de disponibilidade e escalabilidade, elas precisam oferecer o mesmo conteúdo para todo mundo que as acesse. De uma forma grosseira e simplista, sempre o exato mesmo conteúdo vai ser retornado para todo mundo que acessar aquela tal página, aquele recurso estático, a não ser que depois dessa primeira interação essa página estática busque informações personalizadas em outro lug ar, como, por exemplo, uma
API. Então, no caso de uma API, para cada acesso que um endpoint dela receber, você pode decidir o que quer fazer e o que quer devolver como resposta. E isso é fundamental para você programar qualquer sistema que tem por exemplo um cadastro, login, envio de mensagens, envio de pedidos ou consulta de informações, principalmente informações privadas do usuário que está autenticado. E colocando todo mundo na mesma página sobre o que a gente tem em mão s até agora, nos vídeos passados, a gente criou
um projeto chamado "ideia única" utilizando o framework Next.js e o projeto está bem simples por enquanto. Mas o massa é que o código está no GitHub, e toda vez que a gente faz um push para a branch main, as modificações são automaticamente publicadas num site real na internet, naquele domínio hospedarsitegratis, que nos vídeos passados a gente comprou e configurou lá na Vercel. E apesar de que a gente precisou pagar pelo domínio .com.b r, super normal... A hospedagem na Vercel foi gratuita e
continua sendo para comportar sua própria API. Assim... Melhor do que isso não fica. E voltando para o projeto, o framework Next.js possui uma pasta bem especial chamada pages, e é nessa pasta que ficam as nossas páginas web, aquelas que no final das contas vão aparecer no seu navegador. A gente pode ver que o index.js é o responsável pela home do site e ele não deixa de ser um componente tradicional em React, até porque ele vai renderizar o nosso front-end. E é importante destacar isso de ele
ser um componente React para o nosso front-end, porque quando você entra nas camadas da API, você se afasta do React e do front-end e entra mais profundamente na camada do back-end. Isso é ótimo porque você pode, mais do que nunca, fazer coisas sensíveis que um servidor faz, como por exemplo, abrir conexão com banco de dados e gravar e ler dados ou consultar uma outra API utilizando uma chave de acesso privada su per sensível e que é um exemplo que a gente vai implementar hoje, inclusive. E
apesar de que você pode fazer essas coisas que eu citei também com páginas estáticas através de rotinas como o getStaticProps que a gente viu nos vídeos passados... Com uma API, você pode comportar dados em tempo real, em tempo de execução, sem estar nada atrelado ao layout das coisas, ao front-end. Bom... Então, sabe aquela pasta especial "pages"? Ela é tão especial que eu consigo criar uma outra pas ta especial dentro dela chamada "api". E agora dentro dela, eu posso criar as rotas da nossa API
através de arquivos, como por exemplo, criar uma rota que vai ficar disponível no endereço /api/tempo ao criar o arquivo tempo.js dentro dessa pasta api. Lembra que o Next.js utiliza File-system routing para as páginas convencionais? Dá para ver aqui a relação entre os arquivos e endereço final dessas páginas. E no caso das rotas da API, continua sendo exatamente a mesma coisa. Todos os ar quivos JavaScript ou TypeScript dentro dessas pastas ou subpastas automaticamente vão ser disponibilizados
como rotas públicas. Colocando a mão na massa fica mais fácil de entender, olha só... Voltando ao arquivo tempo.js, eu vou escrever uma função tradicional em JavaScript e pode levar qualquer nome, mas que recebe dois parâmetros importantes: o request e o response. Tradicionalmente, usando HTTP toda vez que um site pede algo para um servidor, ou toda vez que um aplicativo de cel ular faz a mesma coisa, ambos estão mandando um request para o servidor, um pedido, uma requisição... Um request. E
nesse request, pode-se ou não enviar informações juntos, como por exemplo, se o meu site fizer uma requisição, um request para criar uma nova conta de usuário com esse login e senha aqui, esses dados vão juntos da request. E uma vez feita essa request e ela chega com sucesso no servidor, essa conexão fica presa, ela fica aberta até que o servidor consiga responder. Ou seja, consiga fazer um response. E essa resposta, esse response pode ser por exemplo: "Ok, eu consegui criar essa nova conta,
está aqui o seu ID" ou "Não, não deu certo, esse usuário que você escolheu já foi usado por uma outra pessoa". Independente de qual for o response lá no server-side, algo aqui no client-side vai ficar possivelmente aguardando essa resposta para reagir de acordo. Por isso que nessa função a gente tem disponível esses dois objetos de request e response. Co m o request, a gente pode receber e manipular qualquer valor que venha junto dessa requisição. Ou seja, o login e senha como comentado
antes, seja um cookie de sessão para verificar se o usuário está logado, o ID de um post, produto, ou o que seja. Já o response serve para devolvermos dados e encerrar essa requisição para liberar o client-side ou quem está consumindo a gente de fazer o que quiser com o que acabou de receber como retorno. Bora então implementar o nosso primei ro response? Show! Eu vou começar criando uma variável que vai guardar o tempo atual e isso vai casar perfeitamente com um exemplo um pouco mais para
frente. Bom... Por enquanto, para eu conseguir de fato responder a requisição, que para esse caso, eu quero responder um JSON, basta eu usar no objeto de response um método chamado JSON e colocar o meu objeto lá dentro. E que, por enquanto, eu vou devolver uma propriedade chamada date com a data em GMTString, que fica melhor de le r. Pronto! Está feito o código da nossa API. Eu falei que a explicação ia ser maior que o código. Mas, na verdade, apesar de que o código daquela função tempo está
virtualmente pronta, como que o Next.js vai saber que de dentro de um arquivo JavaScript que pode ter inúmeras funções, é aquela lá que a gente quer que ele use para lidar com o request e o response? Super simples! Basta a gente fazer o export por padrão dessa função que o Next.js vai usar isso como entry point e toda a request que ele receber na rota /api/tempo ele vai "tunelar" para dentro dessa função. Bom, vamos fazer o deploy disso em produção? Massa! E a única coisa que precisa fazer é
empurrar essas alterações para a branch principal, como comentei antes, e enquanto a Vercel trabalha no nosso deploy, eu vou ficar tentando acessar essa nova rota no navegador até ela ir para o ar... E pimba! Está vindo a resposta, muito massinha. Nota que a cada refresh que eu dou, ela computa e me retorna um novo horário como esperado e turma... Se a gente quiser fazer um site que exibe o horário de uma forma tosca, a API já está pronta. E nota que o retorno está vindo todo bonitinho e
formatado, isso não é o Next.js quem está fazendo, é apenas uma extensão que eu instalei no meu Chrome chamada JSON viewer. Ela identifica que você recebeu uma resposta contendo um JSON e o formata de uma forma mais agradável e interativa, porque a resposta original da nossa API é somente assim na verdade. O que é uma delícinha para ser integrado por qualquer outro sistema. Mas está tudo muito fácil para o meu gosto... Bora complicar esse treco? Que tal de dentro da nossa API, a gente buscar
dados de uma outra API que precisa de credencial, dado sensível... E para fazer um trabalho decente nesse ponto, mandatoriamente a gente precisa usar um negócio chamado variáveis de ambiente. A não ser que você queira aparecer na minha newsletter como o Ministério da Saúde apareceu, quando eles colocaram os dados de acesso dentro do HTML! E falando em newsletter, bora implementar aqui dentro da nossa API um recurso que eu implementei lá na página inicial da newsletter? O recurso é esse número de
inscritos que eu pego dinamicamente da API do ConvertKit, o sistema que a gente usa para mandar as edições diárias para a turma. Mas ali, eu implementei usando aquele getStaticProps que eu comentei antes, que inclusive a gente já falou em vídeos passados, mas caso você nã o tenha visto, a explicação é bem simples. O Next.js no processo de build, e que roda uma única vez na hora do deploy, consegue cozinhar essa informação ali dentro da página estática, e entrega essa mesma página para todo
mundo. O detalhe é que junto disso, eu configurei para que essa página seja revalidada, seja gerada novamente do zero a cada um segundo, e parece que esse número sempre está atualizado, e que no final das contas, está. E reimplementar isso em forma de API vai ser uma ótima oportunidade para eu mostrar como usar variáveis de ambiente como eu comentei antes... Mas principalmente para eu te mostrar como escalar a sua API infinitamente, e onde você vai se ferrar lindamente nessa história. É muito
massa! Bom, consultando rapidamente a documentação do ConvertKit, eles fornecem um endpoint que retorna os inscritos da newsletter, onde o único parâmetro obrigatório a se passar é o seu API secret. E de fato, acessando o endpoint e passando junto o API secret, retornou que nesse momento a newsletter está com mais de 44 mil inscritos, inclusive muito obrigado a todo mundo que se inscreveu, e me impressiona a participação de todos vocês de segunda à sexta vendo com a gente as principais notícias
da nossa área. E agora com esse endpoint da ConvertKit funcionando, bora programar a nossa API para que ela faça um request contra esse endpoint, aguardar o response, mastigar os dados, para por exemplo, pegar só o número de inscritos e colocar isso na resposta da nossa API? Massa! E seguindo os padrões e boas práticas de desenvolvimento do Ministério da Saúde, eu vou fazer o fetch desse endpoint e vou colar aqui o endereço com o API secret tudo junto, até bagunçou a tela... Mas, por enquanto, é
isso aí. Em seguida com o response do ConvertKit em mãos, eu vou convertê-lo para JSON e extrair de dentro dele o valor que está na propriedade total_subscribers. Show! Por fim, eu vou colocar isso na resposta da nossa API. E turma, está feito o nosso show de horrores. E rodando o comando npm run dev para subir a nossa API aqui na minha máquina local, ao acessar a página no localhost, mais especificamente aquele nosso novo endpoint, Olha que massinha... Agora está retornando a data e o número de
inscritos. E tirando a zoação com o Ministério da Saúde, o mais importante agora é a gente progressivamente desfazer as brechas de segurança abertas por ter colocado no código uma informação tão sensível quanto o API secret. Mas então se é para tirar o API secret dali, o que a gente vai colocar no lugar, ainda mais se eu quiser continuar programando e testando em localhost? Ótima pergunta e a gente vai colocar no lugar uma variável de ambiente que é uma variável de verdade, mas o valor dela é
alimentado pelo ambiente em que o código está rodando. Então, ora o código pode estar sendo rodado no meu ambiente local, ora no ambiente de build, ou no de produção. Novamente, o código em si vai se manter o mesmo e somente quando esse código for rodado é que o ambiente em que ele está vai injetar os valores finais dessas variáveis especiais. E se você está achando complicado, não é não... Olha só que genial e isso vai realmente te aproximar um pouco mais de ser um programador ou programadora
mais profissional. Primeiro vamos criar uma variável chamada apiSecret, e é ela quem vai receber o valor do ambiente. E como o ambiente passa esses valores por processo em que o código est á rodando, basta acessar o valor contido na variável global process.env ponto o nome da variável que está no ambiente que a gente não criou ainda, mas que por enquanto vamos chamar de CONVERTKIT_API_SECRET. Eu deixei tudo em caixa alta, porque esse é o padrão que se usa para variáveis de ambiente, nada de
especial. E assumindo que a gente vai conseguir estar com esse valor em mãos, vamos substituir o API secret colocado aqui na mão por essa nova variável. E está pronto! Pelo men os, a parte de buscar um valor das variáveis de ambiente, porque se eu rodar o código assim, vai quebrar. E o motivo é que em nenhum lugar eu defini o valor final da variável de ambiente, CONVERTKIT_API_SECRET, correto? esse valor não está definido nem em localhost na minha máquina, nem em um ambiente de produção. Então,
por enquanto, vai dar problema em qualquer ambiente. Mas a boa notícia é que em ambos os ambientes é muito fácil de resolver. Inclusive, lá em produção, a Vercel fe z uma coisa inédita na minha visão. Olha só... Começando pelo ambiente local, eu vou criar na raiz do projeto um arquivo especial chamado .env, onde dentro dele eu vou declarar o nome da variável de ambiente e o seu valor e pronto. A única tristeza é que o ConvertKit não fornece uma API secret de teste para a gente usar na máquina
local. Então, infelizmente por enquanto a gente vai continuar usando a chave de verdade. Pelo menos, esse arquivo especial .env não fica salvo no Git, n o versionamento de código. Aliás, ele não deveria ficar salvo, então verifica se ele está sendo declarado com sucesso dentro do .gitignore do seu projeto. E agora, a única coisa que vai ser transportado para lá e para cá, seja de volta para o GitHub, seja para a Vercel é o código falando que ele quer usar essa variável de ambiente, não o valor
explícito que está na variável de ambiente. E para ver o resultado disso na prática primeiro aqui em localhost, você precisa reiniciar o Nex t.js para que ele leia o arquivo .env e injete os valores de lá no processo. Inclusive, ele avisa isso aqui nos logs. Bom... E dando um refresh na rota da nossa API, a gente pode ver que o número de inscritos continua retornando como esperado, e, inclusive, 78 pessoas se cadastraram nesse meio tempo, muito massinha e muito obrigado. Mas em ambiente de
produção, que é onde esse valor deveria estar guardado de fato, inclusive encriptado... Será que é muito difícil fazer? Não é nã o! Olha que genial o jeito que a Vercel bolou de fazer. Aqui no painel administrativo dela, inclusive tudo o que eu vou mostrar aqui está disponível na conta Hobby que é gratuita, eu vou entrar no meu projeto ideia-unica, clicar em Settings e no menu que aparecer na esquerda, eu vou clicar em Environments Variables, variáveis de ambiente. A tela que aparecer pode
assustar um pouco, mas seguindo os passos fica super simples. No passo 1, a Vercel pergunta qual é o tipo de dado qu e a gente vai usar, para saber se ela precisa encriptar ou não e como é um dado sensível, vamos escolher o tipo secret. Beleza! Com isso, no passo 2, ela pergunta qual o nome e valor... E para não dar bobeira, eu vou copiar e colar o nome lá do arquivo .env e para o valor a mesma coisa. Mas como é um secret e a Vercel vai esconder essa informação inclusive aqui do painel, ela pede
para a gente criar um nome, uma espécie de um apelido para esse segredo, porque você pode compartilhar a té entre outros projetos que você possui dentro da Vercel. Falta agora apenas a gente colocar o valor a ser encriptado e criar de fato esse secret que automaticamente já fica selecionado como o valor para a nossa variável de ambiente. Por último, no passo 3, ela pergunta em quais ambientes a gente deseja que essa variável fique disponível e vamos deixar para ambos ambientes de produção e
homologação. Reforçando que o certo era conseguir ter chaves diferentes para desenvolvimento local, homologação e produção. Com isso feito, vamos clicar em salvar e olha aqui embaixo de fato a nossa variável de ambiente criada. Muito massa! E caso você queira ir um passo além, você pode selecionar essa opção Automatically Expose System Environment Variables para que a Vercel exponha outras variáveis de ambientes dela como por exemplo, qual o ambiente que a aplicação está rodando ou a URL de
deploy e essas coisas são perfeitas para continuous integration e logs. Bom, com tudo feito na Vercel, nos resta fazer o deploy em produção dessa última versão do código que de fato usa a variável de ambiente. Até porque somente os deploys seguintes conseguem capturar essas novas variáveis de ambiente que foram cadastradas. Olha só... Eu primeiro vou me certificar que o arquivo .env não vai ser commitado no repositório. Show! Só tem de fato as modificações no arquivo tempo.js e da mesma forma
que antes, vou commitar, empurrar, fazer deploys essas coisas... E c om essa parte feita, ao dar o refresh no navegador é retornado com sucesso as informações dos inscritos também no ambiente de produção. Novamente, o API Secret não está nesse código, ele foi injetado por uma variável de ambiente lá pela Vercel. 98% delicinha. 98, porque 99% delicinha é o que vem agora... Aprender a escalar infinitamente essa API e onde que você vai se ferrar lindamente nessa história. Primeiro, essa API já está
escalando infinitamente, virtualmente falando, a Vercel já faz isso para você sem precisar fazer configuração alguma e de forma transparente ela vai escalando a API horizontalmente. Então, pode vir uma pancada de requests que ela aguenta tranquilamente. Eu já tive um caso pessoal que comentei num outro vídeo de um endpoint que recebeu 132 mil requests dentro de uma hora, e foi suave. Mas dado isso, onde é que você vai se ferrar nessa história? Simples, toda vez que você resolve um gargalo, você
cria outro. Até no caso dessa nossa API, nes se endpoint que consome a API do ConvertKit. A nossa API vai aguentar pancada de acesso tranquilamente. Quem não vai gostar nada dessa história vai ser a API do ConvertKit. Eles deixam bem claro na documentação que você pode fazer no máximo 120 requisições a cada 60 segundos, depois disso eles retornam erro. Ou se você está se conectando num banco de dados como o PostgreSQL e a API, a camada da aplicacação escalar horizontalmente de uma forma
insana, você pode rapidamente co nsumir todas as conexões do banco. E se você não gerenciar isso, as tentativas e conexões seguintes vão retornar erro, mas isso também é válido para qualquer sistema que você está tentando escalar horizontalmente. Então, são problemas mais avançados, não precisa se desesperar agora, até porque tem uma forma genial de segurar essa carga e não repassar para o banco de dados ou no nosso caso para a API do ConvertKit. E de fato, é uma das coisas mais geniais que eu
aprendi a usar com o combo Next.js + Vercel, que é o cabeçalho stale-while-revalidate na API. Se você viu os vídeos dessa playlist sobre gerar páginas estáticas e como fazê-las se atualizarem, se revalidarem sozinhas, você vai entender na hora o que vai acontecer agora. Se você não viu, sem problema, porque novamente, a explicação também é bem simples. Com um único comando, você consegue "cachear" a resposta de um endpoint da API. E todas as novas requests contra esse endpoint, a Vercel vai
responde r instantaneamente com os valores que estão em cache. Mas o mais massa é que por debaixo dos panos, e sem interromper o acesso de quem está consumindo a API naquele exato momento, a Vercel vai tentar buscar no seu back-end por dados mais atualizados. E se conseguir, ela vai atualizar o cache e todas as novas requisições daí para frente já recebem os novos dados. E isso pode ter um impacto bizarro de positivo na performance do seu site, ou do seu aplicativo, o que seja... Porque às vezes
um endpoint é custoso de ser usado, ele processa informações demais, puxa informações de vários locais e aí demora para responder. Mas uma vez respondido e em cache na Vercel, todas as novas requests dali para frente vão ser instantâneas, vão ser resolvidas de forma instantânea até a Vercel ter o trabalho pesado de ir lá e atualizar os dados e colocar no cache de volta para continuar a resposta instantânea. Vamos ver no código como é absurdamente fácil de implementar isso. Assim... Parece at é
fake. Abrindo de volta o tempo.js, a única coisa que eu vou incluir é um novo comando no response, setando um novo header, que para esse caso é um header responsável pelo controle do cache. E como valor, eu vou definir que o endpoint tenha um cache lá no servidor da Vercel, que dure no mínimo dez segundos e que tenha aquela propriedade de stale-while-revalidate, que é responder instantaneamente as requests enquanto a Vercel tenta atualizar o cache, caso tenha passado esses dez se gundos. E
pronto, está feito! O próximo passo é fazer o deploy dessa alteração e vai acontecer algo interessante com aquele valor que mostra o tempo na resposta da nossa API. Lembra que agora ele está em tempo real, correto? A cada refresh que eu dou contra a API, ele computa e me retorna o tempo exatamente de agora. Mas olha que interessante que fica com o cache de dez segundos lá no servidor da Vercel. Novamente, eu vou fazer o commit de tudo e empurrar lá para a Vercel para ela iniciar o deploy e
enquanto isso, presta atenção nos segundos dessa data aqui. Por enquanto, a Vercel não conseguiu terminar deploy, por isso que a cada refresh que eu faço, a data atualiza como esperado. Mas opa! A Vercel terminou o deploy e o número parou em 49. Excelente! E todo novo refresh que estou fazendo, pode conferir pelo timestamp atual, injetado por aquela extensão JSON Viewer, eu estou recebendo a resposta instantaneamente do cache da Vercel. E depois que passa aqueles dez segundos que eu defini, eu
continuo recebendo a resposta do cache até que a Vercel consiga com sucesso atualizá-lo. Ou seja, mesmo que a API do ConvertKit caia e estoure um erro na minha API, esse endpoint continua em pé, porque a Vercel vai continuar por debaixo dos panos tentando atualizar o cache até que consiga fazer com sucesso. E enquanto não conseguir, para proteger a disponibilidade desse endpoint, ela vai continuar retornando instantaneamente os valores em cache . Ao menos é o resultado que você quer ao definir o
cabeçalho stale-while-revalidate. Mas cuidado! Só implementa isso em endpoints que possuem valores que possam ser compartilhados para todos os seus usuários, para todos os consumidores dessa API. Até porque a resposta dessa API dentro desses dez segundos virou um valor estático na CDN da Vercel. E eu tenho certeza que no produto ou serviço que você construiu ou vai construir tem vários desses endpoints genéricos em que a resposta po deria estar em cache distribuída globalmente de uma forma
instantânea, melhorando muito a usabilidade do seu sistema. E eu comentei antes de 98% delicinha, aí 99%, mas o que seria algo 100% delicinha? Excelente pergunta de novo! E 100% delicinha é aprender o que considero um dos recursos mais avançados no Next.js e que está disponível neste vídeo aqui. Fechado? Valeu! Português (Brasil) vi)
Como Fazer Uma API (o jeito mais fácil e moderno que eu já vi)
196.377 visualizações • 18 de jan. de 2021 • Aprender a programar uma API Rest (REST API) utilizando Variáveis de Ambiente (Environment Variables) é uma habilidade extremamente profissional que um programador ou programadora deve ter quando se trata de Programação Web (Web Development), principalmente quando atreladas a estratégias de cache avançadas como o "stale while revalidate" (e que também vemos como programar dentro deste vídeo). Então se você tem dúvidas sobre "O que é API", "O que é API REST", "O que é um Endpoint", ou "Como usar o process.env para ler a Variavel de Ambiente" e está a procura de um tutorial backend que ensine como usar o Next.js para hospedar a sua API na Vercel de uma forma profissional, este vai ser o melhor vídeo para entrar nesse assunto. Inclusive dentro das "Next Js API Routes" nós vamos ver os conceitos de "Request Response" que é o que move o Desenvolvimento Web nos dias de hoje, incluindo como fazer respostas utilizando JSON. ✅ 𝗟𝗜𝗡𝗞𝗦 𝗖𝗜𝗧𝗔𝗗𝗢𝗦 𝗡𝗢 𝗩Í𝗗𝗘𝗢 ▸ Newsletter sobre Tecnologia: https://filipedeschamps.com.br/newsle... ✅ 𝗢𝗟𝗛𝗔 𝗤𝗨𝗘 𝗠𝗔𝗦𝗦𝗔! ▸ Se essas conversas aqui estão fazendo você perceber coisas diferentes no seu código, ou na sua profissão de desenvolvedor, considera se tornar um Membro da Turma. É muito massa porque dá pra ter uma conversa muito mais próxima e discutir coisas bem diferentes e super importantes do nosso dia a dia: https://www.youtube.com/FilipeDescham... ✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟 ▸ Preguiça: Descobri Como Consertar o Meu Maior Problema https://youtu.be/rHANBi7E2cI ▸ 3 Técnicas Que Eu Uso Para Aprender a Programar Qualquer Coisa https://youtu.be/ZtMzB5CoekE ▸ S.O.L.I.D. fica FÁCIL com Essas Ilustrações https://youtu.be/6SfrO3D4dHM ▸ Eu fiz um dos melhores cursos de Programação do Mundo! https://youtu.be/elIl48sZ3rA ▸ Desafio: 10 projetos rápidos para treinar Programação e conseguir um Emprego https://youtu.be/fYR9L2ZmodM Mostrar menos Mostrar mais
Neste vídeo, eu vou mostrar a forma mais fácil que existe atualmente de como fazer uma API, como colocar em produção num domínio .com.br de verdade, como escalá-la infinitamente, onde você vai se ferrar tentando escalá-la infinitamente, como armazenar segredos, como senhas ou token de acesso de uma forma segura, profissional para te libertar a construir suas próprias APIs REST para serem usadas em qualquer site, aplicativo, ou sistema que você queira integrar para você literalmente conseguir
construir o que quiser daqui para frente, principalmente aquela ideia que só você teve e que já está na hora de sair do papel. E apesar que alguns desses tópicos possam parecer um pouco avançados, do jeito que eu vou mostrar aqui vai ficar muito fácil e realmente qualquer pessoa vai conseguir programar a sua própria API e hospedá-la de graça. E está tudo tão fácil que a explicação que eu vou incrementar ao redor do código, vai ser muito maior do que o próprio código em si. E hoje ain da quando
fizermos o primeiro deploy juntos, você vai pensar: "Tá, mas é só isso de código para ter uma API no ar? Eu fiquei me enrolando todo esse tempo só para isso?" E sim, é pouco código e é sensacional. Este vídeo aqui faz parte de uma playlist de desenvolvimento web, mas você não precisa assistir os outros vídeos para entender este aqui. Até porque nos outros vídeos, eu explico como criar páginas estáticas e elas têm uma limitação fundamental quando comparadas à flexibilidade de uma
API. Necessariamente para que as páginas estáticas consigam atingir o seu nível insano de disponibilidade e escalabilidade, elas precisam oferecer o mesmo conteúdo para todo mundo que as acesse. De uma forma grosseira e simplista, sempre o exato mesmo conteúdo vai ser retornado para todo mundo que acessar aquela tal página, aquele recurso estático, a não ser que depois dessa primeira interação essa página estática busque informações personalizadas em outro lug ar, como, por exemplo, uma
API. Então, no caso de uma API, para cada acesso que um endpoint dela receber, você pode decidir o que quer fazer e o que quer devolver como resposta. E isso é fundamental para você programar qualquer sistema que tem por exemplo um cadastro, login, envio de mensagens, envio de pedidos ou consulta de informações, principalmente informações privadas do usuário que está autenticado. E colocando todo mundo na mesma página sobre o que a gente tem em mão s até agora, nos vídeos passados, a gente criou
um projeto chamado "ideia única" utilizando o framework Next.js e o projeto está bem simples por enquanto. Mas o massa é que o código está no GitHub, e toda vez que a gente faz um push para a branch main, as modificações são automaticamente publicadas num site real na internet, naquele domínio hospedarsitegratis, que nos vídeos passados a gente comprou e configurou lá na Vercel. E apesar de que a gente precisou pagar pelo domínio .com.b r, super normal... A hospedagem na Vercel foi gratuita e
continua sendo para comportar sua própria API. Assim... Melhor do que isso não fica. E voltando para o projeto, o framework Next.js possui uma pasta bem especial chamada pages, e é nessa pasta que ficam as nossas páginas web, aquelas que no final das contas vão aparecer no seu navegador. A gente pode ver que o index.js é o responsável pela home do site e ele não deixa de ser um componente tradicional em React, até porque ele vai renderizar o nosso front-end. E é importante destacar isso de ele
ser um componente React para o nosso front-end, porque quando você entra nas camadas da API, você se afasta do React e do front-end e entra mais profundamente na camada do back-end. Isso é ótimo porque você pode, mais do que nunca, fazer coisas sensíveis que um servidor faz, como por exemplo, abrir conexão com banco de dados e gravar e ler dados ou consultar uma outra API utilizando uma chave de acesso privada su per sensível e que é um exemplo que a gente vai implementar hoje, inclusive. E
apesar de que você pode fazer essas coisas que eu citei também com páginas estáticas através de rotinas como o getStaticProps que a gente viu nos vídeos passados... Com uma API, você pode comportar dados em tempo real, em tempo de execução, sem estar nada atrelado ao layout das coisas, ao front-end. Bom... Então, sabe aquela pasta especial "pages"? Ela é tão especial que eu consigo criar uma outra pas ta especial dentro dela chamada "api". E agora dentro dela, eu posso criar as rotas da nossa API
através de arquivos, como por exemplo, criar uma rota que vai ficar disponível no endereço /api/tempo ao criar o arquivo tempo.js dentro dessa pasta api. Lembra que o Next.js utiliza File-system routing para as páginas convencionais? Dá para ver aqui a relação entre os arquivos e endereço final dessas páginas. E no caso das rotas da API, continua sendo exatamente a mesma coisa. Todos os ar quivos JavaScript ou TypeScript dentro dessas pastas ou subpastas automaticamente vão ser disponibilizados
como rotas públicas. Colocando a mão na massa fica mais fácil de entender, olha só... Voltando ao arquivo tempo.js, eu vou escrever uma função tradicional em JavaScript e pode levar qualquer nome, mas que recebe dois parâmetros importantes: o request e o response. Tradicionalmente, usando HTTP toda vez que um site pede algo para um servidor, ou toda vez que um aplicativo de cel ular faz a mesma coisa, ambos estão mandando um request para o servidor, um pedido, uma requisição... Um request. E
nesse request, pode-se ou não enviar informações juntos, como por exemplo, se o meu site fizer uma requisição, um request para criar uma nova conta de usuário com esse login e senha aqui, esses dados vão juntos da request. E uma vez feita essa request e ela chega com sucesso no servidor, essa conexão fica presa, ela fica aberta até que o servidor consiga responder. Ou seja, consiga fazer um response. E essa resposta, esse response pode ser por exemplo: "Ok, eu consegui criar essa nova conta,
está aqui o seu ID" ou "Não, não deu certo, esse usuário que você escolheu já foi usado por uma outra pessoa". Independente de qual for o response lá no server-side, algo aqui no client-side vai ficar possivelmente aguardando essa resposta para reagir de acordo. Por isso que nessa função a gente tem disponível esses dois objetos de request e response. Co m o request, a gente pode receber e manipular qualquer valor que venha junto dessa requisição. Ou seja, o login e senha como comentado
antes, seja um cookie de sessão para verificar se o usuário está logado, o ID de um post, produto, ou o que seja. Já o response serve para devolvermos dados e encerrar essa requisição para liberar o client-side ou quem está consumindo a gente de fazer o que quiser com o que acabou de receber como retorno. Bora então implementar o nosso primei ro response? Show! Eu vou começar criando uma variável que vai guardar o tempo atual e isso vai casar perfeitamente com um exemplo um pouco mais para
frente. Bom... Por enquanto, para eu conseguir de fato responder a requisição, que para esse caso, eu quero responder um JSON, basta eu usar no objeto de response um método chamado JSON e colocar o meu objeto lá dentro. E que, por enquanto, eu vou devolver uma propriedade chamada date com a data em GMTString, que fica melhor de le r. Pronto! Está feito o código da nossa API. Eu falei que a explicação ia ser maior que o código. Mas, na verdade, apesar de que o código daquela função tempo está
virtualmente pronta, como que o Next.js vai saber que de dentro de um arquivo JavaScript que pode ter inúmeras funções, é aquela lá que a gente quer que ele use para lidar com o request e o response? Super simples! Basta a gente fazer o export por padrão dessa função que o Next.js vai usar isso como entry point e toda a request que ele receber na rota /api/tempo ele vai "tunelar" para dentro dessa função. Bom, vamos fazer o deploy disso em produção? Massa! E a única coisa que precisa fazer é
empurrar essas alterações para a branch principal, como comentei antes, e enquanto a Vercel trabalha no nosso deploy, eu vou ficar tentando acessar essa nova rota no navegador até ela ir para o ar... E pimba! Está vindo a resposta, muito massinha. Nota que a cada refresh que eu dou, ela computa e me retorna um novo horário como esperado e turma... Se a gente quiser fazer um site que exibe o horário de uma forma tosca, a API já está pronta. E nota que o retorno está vindo todo bonitinho e
formatado, isso não é o Next.js quem está fazendo, é apenas uma extensão que eu instalei no meu Chrome chamada JSON viewer. Ela identifica que você recebeu uma resposta contendo um JSON e o formata de uma forma mais agradável e interativa, porque a resposta original da nossa API é somente assim na verdade. O que é uma delícinha para ser integrado por qualquer outro sistema. Mas está tudo muito fácil para o meu gosto... Bora complicar esse treco? Que tal de dentro da nossa API, a gente buscar
dados de uma outra API que precisa de credencial, dado sensível... E para fazer um trabalho decente nesse ponto, mandatoriamente a gente precisa usar um negócio chamado variáveis de ambiente. A não ser que você queira aparecer na minha newsletter como o Ministério da Saúde apareceu, quando eles colocaram os dados de acesso dentro do HTML! E falando em newsletter, bora implementar aqui dentro da nossa API um recurso que eu implementei lá na página inicial da newsletter? O recurso é esse número de
inscritos que eu pego dinamicamente da API do ConvertKit, o sistema que a gente usa para mandar as edições diárias para a turma. Mas ali, eu implementei usando aquele getStaticProps que eu comentei antes, que inclusive a gente já falou em vídeos passados, mas caso você nã o tenha visto, a explicação é bem simples. O Next.js no processo de build, e que roda uma única vez na hora do deploy, consegue cozinhar essa informação ali dentro da página estática, e entrega essa mesma página para todo
mundo. O detalhe é que junto disso, eu configurei para que essa página seja revalidada, seja gerada novamente do zero a cada um segundo, e parece que esse número sempre está atualizado, e que no final das contas, está. E reimplementar isso em forma de API vai ser uma ótima oportunidade para eu mostrar como usar variáveis de ambiente como eu comentei antes... Mas principalmente para eu te mostrar como escalar a sua API infinitamente, e onde você vai se ferrar lindamente nessa história. É muito
massa! Bom, consultando rapidamente a documentação do ConvertKit, eles fornecem um endpoint que retorna os inscritos da newsletter, onde o único parâmetro obrigatório a se passar é o seu API secret. E de fato, acessando o endpoint e passando junto o API secret, retornou que nesse momento a newsletter está com mais de 44 mil inscritos, inclusive muito obrigado a todo mundo que se inscreveu, e me impressiona a participação de todos vocês de segunda à sexta vendo com a gente as principais notícias
da nossa área. E agora com esse endpoint da ConvertKit funcionando, bora programar a nossa API para que ela faça um request contra esse endpoint, aguardar o response, mastigar os dados, para por exemplo, pegar só o número de inscritos e colocar isso na resposta da nossa API? Massa! E seguindo os padrões e boas práticas de desenvolvimento do Ministério da Saúde, eu vou fazer o fetch desse endpoint e vou colar aqui o endereço com o API secret tudo junto, até bagunçou a tela... Mas, por enquanto, é
isso aí. Em seguida com o response do ConvertKit em mãos, eu vou convertê-lo para JSON e extrair de dentro dele o valor que está na propriedade total_subscribers. Show! Por fim, eu vou colocar isso na resposta da nossa API. E turma, está feito o nosso show de horrores. E rodando o comando npm run dev para subir a nossa API aqui na minha máquina local, ao acessar a página no localhost, mais especificamente aquele nosso novo endpoint, Olha que massinha... Agora está retornando a data e o número de
inscritos. E tirando a zoação com o Ministério da Saúde, o mais importante agora é a gente progressivamente desfazer as brechas de segurança abertas por ter colocado no código uma informação tão sensível quanto o API secret. Mas então se é para tirar o API secret dali, o que a gente vai colocar no lugar, ainda mais se eu quiser continuar programando e testando em localhost? Ótima pergunta e a gente vai colocar no lugar uma variável de ambiente que é uma variável de verdade, mas o valor dela é
alimentado pelo ambiente em que o código está rodando. Então, ora o código pode estar sendo rodado no meu ambiente local, ora no ambiente de build, ou no de produção. Novamente, o código em si vai se manter o mesmo e somente quando esse código for rodado é que o ambiente em que ele está vai injetar os valores finais dessas variáveis especiais. E se você está achando complicado, não é não... Olha só que genial e isso vai realmente te aproximar um pouco mais de ser um programador ou programadora
mais profissional. Primeiro vamos criar uma variável chamada apiSecret, e é ela quem vai receber o valor do ambiente. E como o ambiente passa esses valores por processo em que o código est á rodando, basta acessar o valor contido na variável global process.env ponto o nome da variável que está no ambiente que a gente não criou ainda, mas que por enquanto vamos chamar de CONVERTKIT_API_SECRET. Eu deixei tudo em caixa alta, porque esse é o padrão que se usa para variáveis de ambiente, nada de
especial. E assumindo que a gente vai conseguir estar com esse valor em mãos, vamos substituir o API secret colocado aqui na mão por essa nova variável. E está pronto! Pelo men os, a parte de buscar um valor das variáveis de ambiente, porque se eu rodar o código assim, vai quebrar. E o motivo é que em nenhum lugar eu defini o valor final da variável de ambiente, CONVERTKIT_API_SECRET, correto? esse valor não está definido nem em localhost na minha máquina, nem em um ambiente de produção. Então,
por enquanto, vai dar problema em qualquer ambiente. Mas a boa notícia é que em ambos os ambientes é muito fácil de resolver. Inclusive, lá em produção, a Vercel fe z uma coisa inédita na minha visão. Olha só... Começando pelo ambiente local, eu vou criar na raiz do projeto um arquivo especial chamado .env, onde dentro dele eu vou declarar o nome da variável de ambiente e o seu valor e pronto. A única tristeza é que o ConvertKit não fornece uma API secret de teste para a gente usar na máquina
local. Então, infelizmente por enquanto a gente vai continuar usando a chave de verdade. Pelo menos, esse arquivo especial .env não fica salvo no Git, n o versionamento de código. Aliás, ele não deveria ficar salvo, então verifica se ele está sendo declarado com sucesso dentro do .gitignore do seu projeto. E agora, a única coisa que vai ser transportado para lá e para cá, seja de volta para o GitHub, seja para a Vercel é o código falando que ele quer usar essa variável de ambiente, não o valor
explícito que está na variável de ambiente. E para ver o resultado disso na prática primeiro aqui em localhost, você precisa reiniciar o Nex t.js para que ele leia o arquivo .env e injete os valores de lá no processo. Inclusive, ele avisa isso aqui nos logs. Bom... E dando um refresh na rota da nossa API, a gente pode ver que o número de inscritos continua retornando como esperado, e, inclusive, 78 pessoas se cadastraram nesse meio tempo, muito massinha e muito obrigado. Mas em ambiente de
produção, que é onde esse valor deveria estar guardado de fato, inclusive encriptado... Será que é muito difícil fazer? Não é nã o! Olha que genial o jeito que a Vercel bolou de fazer. Aqui no painel administrativo dela, inclusive tudo o que eu vou mostrar aqui está disponível na conta Hobby que é gratuita, eu vou entrar no meu projeto ideia-unica, clicar em Settings e no menu que aparecer na esquerda, eu vou clicar em Environments Variables, variáveis de ambiente. A tela que aparecer pode
assustar um pouco, mas seguindo os passos fica super simples. No passo 1, a Vercel pergunta qual é o tipo de dado qu e a gente vai usar, para saber se ela precisa encriptar ou não e como é um dado sensível, vamos escolher o tipo secret. Beleza! Com isso, no passo 2, ela pergunta qual o nome e valor... E para não dar bobeira, eu vou copiar e colar o nome lá do arquivo .env e para o valor a mesma coisa. Mas como é um secret e a Vercel vai esconder essa informação inclusive aqui do painel, ela pede
para a gente criar um nome, uma espécie de um apelido para esse segredo, porque você pode compartilhar a té entre outros projetos que você possui dentro da Vercel. Falta agora apenas a gente colocar o valor a ser encriptado e criar de fato esse secret que automaticamente já fica selecionado como o valor para a nossa variável de ambiente. Por último, no passo 3, ela pergunta em quais ambientes a gente deseja que essa variável fique disponível e vamos deixar para ambos ambientes de produção e
homologação. Reforçando que o certo era conseguir ter chaves diferentes para desenvolvimento local, homologação e produção. Com isso feito, vamos clicar em salvar e olha aqui embaixo de fato a nossa variável de ambiente criada. Muito massa! E caso você queira ir um passo além, você pode selecionar essa opção Automatically Expose System Environment Variables para que a Vercel exponha outras variáveis de ambientes dela como por exemplo, qual o ambiente que a aplicação está rodando ou a URL de
deploy e essas coisas são perfeitas para continuous integration e logs. Bom, com tudo feito na Vercel, nos resta fazer o deploy em produção dessa última versão do código que de fato usa a variável de ambiente. Até porque somente os deploys seguintes conseguem capturar essas novas variáveis de ambiente que foram cadastradas. Olha só... Eu primeiro vou me certificar que o arquivo .env não vai ser commitado no repositório. Show! Só tem de fato as modificações no arquivo tempo.js e da mesma forma
que antes, vou commitar, empurrar, fazer deploys essas coisas... E c om essa parte feita, ao dar o refresh no navegador é retornado com sucesso as informações dos inscritos também no ambiente de produção. Novamente, o API Secret não está nesse código, ele foi injetado por uma variável de ambiente lá pela Vercel. 98% delicinha. 98, porque 99% delicinha é o que vem agora... Aprender a escalar infinitamente essa API e onde que você vai se ferrar lindamente nessa história. Primeiro, essa API já está
escalando infinitamente, virtualmente falando, a Vercel já faz isso para você sem precisar fazer configuração alguma e de forma transparente ela vai escalando a API horizontalmente. Então, pode vir uma pancada de requests que ela aguenta tranquilamente. Eu já tive um caso pessoal que comentei num outro vídeo de um endpoint que recebeu 132 mil requests dentro de uma hora, e foi suave. Mas dado isso, onde é que você vai se ferrar nessa história? Simples, toda vez que você resolve um gargalo, você
cria outro. Até no caso dessa nossa API, nes se endpoint que consome a API do ConvertKit. A nossa API vai aguentar pancada de acesso tranquilamente. Quem não vai gostar nada dessa história vai ser a API do ConvertKit. Eles deixam bem claro na documentação que você pode fazer no máximo 120 requisições a cada 60 segundos, depois disso eles retornam erro. Ou se você está se conectando num banco de dados como o PostgreSQL e a API, a camada da aplicacação escalar horizontalmente de uma forma
insana, você pode rapidamente co nsumir todas as conexões do banco. E se você não gerenciar isso, as tentativas e conexões seguintes vão retornar erro, mas isso também é válido para qualquer sistema que você está tentando escalar horizontalmente. Então, são problemas mais avançados, não precisa se desesperar agora, até porque tem uma forma genial de segurar essa carga e não repassar para o banco de dados ou no nosso caso para a API do ConvertKit. E de fato, é uma das coisas mais geniais que eu
aprendi a usar com o combo Next.js + Vercel, que é o cabeçalho stale-while-revalidate na API. Se você viu os vídeos dessa playlist sobre gerar páginas estáticas e como fazê-las se atualizarem, se revalidarem sozinhas, você vai entender na hora o que vai acontecer agora. Se você não viu, sem problema, porque novamente, a explicação também é bem simples. Com um único comando, você consegue "cachear" a resposta de um endpoint da API. E todas as novas requests contra esse endpoint, a Vercel vai
responde r instantaneamente com os valores que estão em cache. Mas o mais massa é que por debaixo dos panos, e sem interromper o acesso de quem está consumindo a API naquele exato momento, a Vercel vai tentar buscar no seu back-end por dados mais atualizados. E se conseguir, ela vai atualizar o cache e todas as novas requisições daí para frente já recebem os novos dados. E isso pode ter um impacto bizarro de positivo na performance do seu site, ou do seu aplicativo, o que seja... Porque às vezes
um endpoint é custoso de ser usado, ele processa informações demais, puxa informações de vários locais e aí demora para responder. Mas uma vez respondido e em cache na Vercel, todas as novas requests dali para frente vão ser instantâneas, vão ser resolvidas de forma instantânea até a Vercel ter o trabalho pesado de ir lá e atualizar os dados e colocar no cache de volta para continuar a resposta instantânea. Vamos ver no código como é absurdamente fácil de implementar isso. Assim... Parece at é
fake. Abrindo de volta o tempo.js, a única coisa que eu vou incluir é um novo comando no response, setando um novo header, que para esse caso é um header responsável pelo controle do cache. E como valor, eu vou definir que o endpoint tenha um cache lá no servidor da Vercel, que dure no mínimo dez segundos e que tenha aquela propriedade de stale-while-revalidate, que é responder instantaneamente as requests enquanto a Vercel tenta atualizar o cache, caso tenha passado esses dez se gundos. E
pronto, está feito! O próximo passo é fazer o deploy dessa alteração e vai acontecer algo interessante com aquele valor que mostra o tempo na resposta da nossa API. Lembra que agora ele está em tempo real, correto? A cada refresh que eu dou contra a API, ele computa e me retorna o tempo exatamente de agora. Mas olha que interessante que fica com o cache de dez segundos lá no servidor da Vercel. Novamente, eu vou fazer o commit de tudo e empurrar lá para a Vercel para ela iniciar o deploy e
enquanto isso, presta atenção nos segundos dessa data aqui. Por enquanto, a Vercel não conseguiu terminar deploy, por isso que a cada refresh que eu faço, a data atualiza como esperado. Mas opa! A Vercel terminou o deploy e o número parou em 49. Excelente! E todo novo refresh que estou fazendo, pode conferir pelo timestamp atual, injetado por aquela extensão JSON Viewer, eu estou recebendo a resposta instantaneamente do cache da Vercel. E depois que passa aqueles dez segundos que eu defini, eu
continuo recebendo a resposta do cache até que a Vercel consiga com sucesso atualizá-lo. Ou seja, mesmo que a API do ConvertKit caia e estoure um erro na minha API, esse endpoint continua em pé, porque a Vercel vai continuar por debaixo dos panos tentando atualizar o cache até que consiga fazer com sucesso. E enquanto não conseguir, para proteger a disponibilidade desse endpoint, ela vai continuar retornando instantaneamente os valores em cache . Ao menos é o resultado que você quer ao definir o
cabeçalho stale-while-revalidate. Mas cuidado! Só implementa isso em endpoints que possuem valores que possam ser compartilhados para todos os seus usuários, para todos os consumidores dessa API. Até porque a resposta dessa API dentro desses dez segundos virou um valor estático na CDN da Vercel. E eu tenho certeza que no produto ou serviço que você construiu ou vai construir tem vários desses endpoints genéricos em que a resposta po deria estar em cache distribuída globalmente de uma forma
instantânea, melhorando muito a usabilidade do seu sistema. E eu comentei antes de 98% delicinha, aí 99%, mas o que seria algo 100% delicinha? Excelente pergunta de novo! E 100% delicinha é aprender o que considero um dos recursos mais avançados no Next.js e que está disponível neste vídeo aqui. Fechado? Valeu! Português (Brasil) vi)
0 resposta a "Como Fazer Uma API (o jeito mais fácil e moderno que eu já vi)"
Postar um comentário