pessoal vamos falar de mais um carinha aqui que é serverless a gente vai acabar entrando nele mais pra frente então no próximo hands-on possivelmente a gente não vai entrar tanto no API Gateway mas mais pra frente vocês vão ver bastante esse carinha e eu já trouxe ele aqui pra gente dar uma olhada e a gente já entender como ele funciona a gente já falou dele um pouco nos capítulos anteriores mas ao longo do treinamento a gente vai aprofundar mais o que eu o que eu peguei foi é o peguei tem é também como os outros que já fala que o esquece ns lambdé assim por diante um cara totalmente gerenciado pela ws que você não precisa se preocupar com toda a parte infla como já falei dos demais então isso repete pra ele tá bom é quando está gente tá falando do API Gateway, ele não é nada mais do que um porteiro, vamos pensar desse jeito, ele é o cara que decide ali quem entra ou quem não entra dentro da sua aplicação, ele tem mais coisas que ele pode fazer aqui no meio do caminho, mas a grande ideia dele é pra monitorar e proteger as APIs tá bom? então pra gente a gente vai olhar pra esse cara o tempo todo sobre uma ótica de como a gente faz o uso das nossas APIs e como a gente protege as nossas APIs. Essa vai ser a grande ideia aqui dentro do API Gateway. Ele vai fazer uma abstração do que é segurança, o que é carga de trabalho que está entrando para dentro da API, e a API depois vai ficar responsável por lógica de negócio e assim por diante. O API Gateway, então, como eu estava falando, ele é um porteiro para as aplicações. Ele vai fazer o gerenciamento de entrada e de tráfego de saída das APIs e que aqui vai também a capacidade de usar tanto APIs RESTful quanto WebSocket. Qual que é a grande diferença que a gente está falando aqui? quanto o WebSocket. Qual que é a grande diferença que a gente está falando aqui? Quando eu estou falando de uma API RESTful e usando API Gateway para isso, são por exemplo, vamos dar um exemplo aqui de reserva de quarto de hotel. Ali você consegue consultar os quartos que tem disponíveis, fazer a reserva de um quarto, depois cancelar a reserva, assim por diante. Esse tipo de ação é muito comum para você usar um API Gateway com API RESTful, porque daí você vai estar fazendo ali uma ideia de cliente servidor, você está todo o tempo indo lá, olhando uma coisa e voltando, e assim por diante. Então você está fazendo o consumo, depois você volta e segue sua ação. Para esse tipo de comunicação o APGate funciona muito bem. Mas ele também pode ser usado para WebSocket, que é diferente. É uma comunicação bidirecional, uma coisa mais rápida nesse papo aqui. Então pensa que, por exemplo, no WebSocket a gente está falando de um de, por exemplo, bolsa de valores. Você ali o o dado da atualização da dos das ações rolando tempo todo está indo e voltando como se fosse um um tempo real da coisa acontecendo com esse tipo de caso de uso faz mais sentido usar o websocket para os dois o apgator ele vai estar preparado aqui pra trabalhar beleza o apgator ele tem algumas coisas aqui de de configuração e gerenciamento tá bom quando está falando da configuração e gerenciamento a uma das primeiras coisas que a gente faz é a definição das rotas está a definição das rotas não é nada mais do que você entender quais são as rotas que a gente vai deixar entrar, quais são as pessoas que vão poder, as rotas que vão poder acessar a nossa PAYGATE, tá? E as ações que devem ser tomadas depois que essas rotas, elas acessam a nossa PAYGATE. Então, basicamente, ela vai entender quem está acessando ela e para quem que ela tem que direcionar esse acesso, tá bom? São basicamente essas as definições ali de rota. Você define também o modelo de integração. Quando a gente está falando do modelo de integração, você vai decidir aqui como que as solicitações vão acionar o seu back-end e como que eles vão retornar para o seu cliente. Aqui tem algumas coisas que a gente pode fazer que eu vou falar na sequência, mas nesse modelo de integração tem que tomar um pouco de cuidado, tá? A gente vai detalhar mais um pouquinho. E tem o controle de acesso, que você consegue fazer como todos os demais, quem vai poder acessar sua PayGate e quem não. Nesse caso, o controle de acesso é muito detalhado, muito específico. É legal você prestar bastante atenção nesse cara que ele tem bastante configuração para ser feito beleza e quando está falando de limite de taxa de cota é essa parte eu acho muito importante de pensar tá a gente não pode esquecer dela quando está falando dessa limite de taxa de cota o seguinte imagina que eu falei olha api do zezinho pode acessar a minha API. Ou o front-end do hotel pode acessar a minha API. Nessa hora, é importante a gente colocar o limite de acessos que a gente vai dar para cada um desses caras. Porque qual que é o ponto? Por algumas vezes, você pode ter um tipo de ataque na sua API para a galera tentar buscar, por exemplo, de ataque na sua API pra galera tentar buscar por exemplo ataque de negativa ficar buscando lá, sei lá eu tento buscar vários CPFs até achar um que tem na sua base, ou assim por diante entendeu? Num ataque desse se você tiver um limite de taxa de cota aqui, você consegue reduzir esse tipo de ataque, ou até pior, imagina que você tem um cara te atacando beleza? Ele tá ali te atacando, ele não vai conseguir entrar, não está conseguindo buscar dado nenhum, fazer nenhum dado de negativa para você estar no front, por exemplo. Mas ele está fazendo um ataque ali, está vindo várias vezes buscar alguma coisa. E a sua API por trás sofrendo ali, trabalhando igual uma doida, atrás de um monte de informação que não tem nem mais sentido então aqui na peguei que você consegue fazer esse controle de ação de si quantas vezes você vai deixar aquela o rl aquele chamador bater na sua pele pra ela não ficar sendo sobrecarregada então você entendeu toda toda essa estratégia de api que você colocaria dentro dela para determinar se você está tendo muito acesso de quem pode ter acesso a ela etc se abstrai e joga para dentro do gateway deixando desacoplado e o gateway fica com esse trabalho para resolver lá e por ele ser gerenciado lá pela AWS você tem menos ainda dor de cabeça com infra e essas coisas, tá bom? Tem algumas funcionalidades avançadas que a gente acaba usando no dia a dia e que de novo tem que tomar muito cuidado, tem essa daqui que é a transformação de solicitações e respostas. Qual que é a ideia? Imagina que você tem o seu back-end ali e você está tentando proteger ele de não ter tantas alterações. E você tem uma camada de entrada vindo com uma mensagem que às vezes muda de um para outro. Então, imagina que você está tendo vários chamadores e cada chamador pode ter tido um tipo de busca, de mensagem entrando, de chamada na sua API e você precisa fazer alguma abstração aqui dentro para depois chamar a sua API, propriamente dita. Para coisas simples, quer dizer, na verdade o API permite que você faça isso dentro dele. Então se você quiser ficar fazendo transformação de mensagem para proteger o seu back-end e levar para o back-end só a mensagem que já é padronizada do seu sistema, top, a sua requisição já vai entrar lá, é legal. Só que quando você começa a aumentar muito isso, o API Gateway acaba virando uma peça muito grande, o que não é para ser. O API Gateway é para ele ser mais simples, ele é para ele ter como maior linha de raciocínio a quem vai entrar como vai entrar e essa defesa basicamente se a gente parar para pensar não é a visão dele ter que ficar fazendo mudança de mensagem mas você pode usar o que eu dou de dica é ele permite que você use isso use com cuidado quando você tiver uma coisinha ou outra quando for uma coisa simples se você tiver uma alta complexidade para mim já virou regra de negócio você tem que ter algum tipo de ACL pra dentro do seu sistema pra resolver isso você não deveria estar trazendo isso pra dentro do API Gateway depois você vai ficar copado com esse API Gateway que também, como eu falei vai te dar um lock-in com a sua empresa ali de provedora cloud, lembra? esse cara é serverless. Então, se você trouxer para ele todo esse tipo de lógica, você deve estar pensando para mim, pô, eu posso usar o API Gateway como uma série? Pode, mas se você fizer isso dentro do API Gateway, você vai estar com o lock-in com a sua empresa, beleza? Então, você vai estar, por exemplo, aqui no nosso caso, com o lock-in com a AWS. E depois, se você tiver que mudar o seu sistema de lugar, toda essa lógica de então a minha ideia é se for uma coisa simples, beleza fazer dentro se for uma coisa mais complexa, leva pra fora do API Gateway que eu acho que faz mais sentido, beleza? outra coisa que você pode fazer também são os autorizadores aqui que eles são customizados e quando a gente está falando de autorizador customizado é que você pode usar um Lambda junto com o seu API Gateway, por exemplo pra validar token, então você pode fazer uma validação maior aqui não só o rl está chegando etc mas você vai lidar um tolki está chegando batendo numa lambda funciona com seus o apg e tino junto com a lambda para garantir ainda mais que quem está entrando é que deveria entrar no acesso à sua pele beleza e o de sempre aqui que a gente tem que olhar também o monitoramento e análise disso como conectar esse cara no CloudWatch é necessário para você tanto ver a saúde do API Gateway, quanto até ver a saúde da sua API, porque você vai estar sabendo o que está batendo lá sim ou não, está tendo resposta sim ou não. Você consegue colocar tudo nesse monitoramento e saber desde a porta de entrada quem está chegando. Uma outra coisa que também acontece muito, eu vejo algumas pessoas colocando o CloudWatch na API e não põe no API Gateway e daí você perde um espaço aqui de log e daí se por exemplo seu API Gateway está travando alguém, não está deixando alguém entrar por alguma política que você falhou, você não vai nem saber, então é legal você colocar o CloudWatch lendo aqui do API Gateway também, beleza gente?