Olá pessoal, sejam muito bem-vindos a mais uma aula. Nesta aula nós falaremos sobre algo que talvez vocês já estejam se questionando, que é o motivo de nós termos aqui em todas as nossas classes, esse prefixo CFN. Então nós temos aqui CFN VPC, CFN Internet Gateway, CFN VPC Gateway Attachment e assim por diante. E o motivo da estranheza é porque no nosso primeiro exemplo, onde nós criamos ali um bucket, E o motivo da estranheza é porque no nosso primeiro exemplo, onde nós criamos um bucket, nós não tínhamos isso. Nós podemos observar aqui em example stack que nós criamos um bucket, mas essa classe não possui esse CFN. E é claro que existe um motivo para isso, não é por acaso. Todas essas classes que possuem esse prefixo, elas são as classes que nós chamamos de Construct Level 1, ou Construtor de nível 1, que é o menor nível de abstração que nós temos. Nós já sabemos que quando nós estamos criando um projeto em CDK, na verdade, nós estamos abstraindo a lógica, a complexidade de criar um template CloudFormation. Então, quando nós sintetizamos o nosso projeto, nós, na verdade, criamos um projeto CloudFormation. Então, quando nós sintetizamos o nosso projeto, nós na verdade criamos um projeto CloudFormation, um template CloudFormation. E quando nós trabalhamos com esses construtores de nível 1 que possuem esse prefixo, nós temos um mapeamento bem direto entre o que nós definimos aqui nas propriedades e o recurso que é criado lá no template CloudFormation. Então, geralmente você não vai ver nada, nenhum recurso adicional sendo criado ou nada muito complexo sendo adicionado lá no template CloudFormation, tá? Geralmente o template CloudFormation vai ser um reflexo disso que você definiu aqui, beleza? Então, se eu tivesse criado somente uma VPC aqui, nós teríamos somente essa VPC, tá? Nós poderíamos, inclusive, para nós vermos um exemplo, tá? Eu vou comentar aqui todos esses recursos e vou criar somente essa VPC. Deixa eu abrir aqui um terminal e nós vamos agora executar o seguinte. Nós vamos executar o cdk, synth e eu vou direcionar o output para template.eml e vamos verificar o que é gerado aqui para nós vamos aguardar, beleza, e aqui como já era de se esperar foi criado um recurso do tipo EC2VPC com esse CIDER block e é isso, aqui nós temos os metadata e as conditions que são sempre adicionadas aos nossos templates. Porém, existem algumas outras classes que nós podemos utilizar que já oferecem um nível de abstração bem maior. Então, geralmente essas classes criam outros recursos, elas podem criar, por exemplo, permissões, quando nós relacionamos dois recursos diferentes e um recurso precisa ter a permissão de acesso a outro recurso, às vezes essas policies já são criadas automaticamente, dependendo do construtor ou da classe que você está utilizando. Eu recomendo que você dê uma olhada aqui nessa documentação da AWS que fala sobre esses constructs. Então, um construct nada mais é do que um recurso que é provisionado e que você define no seu projeto CDK. E aqui nós temos os níveis, os níveis de abstração. Como eu já comentei, o nível 1, que é o mais baixo, que é o nível mais próximo do CloudFormation. Temos o nível 2, que já oferece uma API que foi pensada para nos ajudar na nossa experiência como desenvolvedor, que possui métodos que vão nos auxiliar a construir os nossos recursos. Então, já é uma experiência muito melhor e já facilita bastante o nosso trabalho. E por fim, nós temos o nível 3 também, que já é um nível bem mais alto de abstração, que pode ser considerado até como, eu diria que seria um módulo, porque ele cria vários recursos e nos auxilia bastante, utilizando até alguns padrões muito bem conhecidos de mercado. Então, às vezes, com poucas linhas de código, você cria muitos recursos. Ele, inclusive, dá o exemplo aqui do Application Load Balanced Fargate Service, que vai criar ali o seu serviço no Fargate, já com um Application Load Balance, com as regras que você precisa, com Security Groups, e assim por diante. Então, temos esses três níveis de abstração. E para nós vermos o exemplo, aqui eu gostaria de comentar esse VPC. Então, nós vimos aqui que mantendo, utilizando, na verdade, esse CFM VPC, o nosso CloudFormation gera somente um recurso do tipo VPC. Agora, vamos utilizar um carinha aqui que é do nível 2, tá? Beleza? Que é esse VPC. Na verdade, eu não tenho nem certeza se esse cara aqui é do nível 2 ou do nível 3. Na documentação ele não fala, ele não especifica qual nível que é, mas geralmente os níveis 3 eles terminam com service, ou com pattern, ou com algo do tipo. Então eu imagino que esse cara aqui seria mais do nível 2. Aqui então nós estamos utilizando o mesmo módulo, porém nós estamos utilizando a classe VPC. Nós passamos a stack, passamos o prefixo e passamos o CIDER block. Só isso, não informamos mais nada. Agora vamos dar uma olhada na diferença aqui do arquivo template.yml gerado quando nós rodamos a sintetização. quando nós rodamos a sintetização, tá? Beleza? Agora nós vamos observar aqui o arquivo template e nós temos o seguinte. Nós temos a nossa VPC. Aqui nós já temos algumas outras propriedades adicionais, tá? Que nós não especificamos. Nós temos uma subnet e ele já divide essa subnet aqui em uma máscara barra 18, tá? Então ele fez isso automaticamente, nós não especificamos. Ele criou uma route table, ele associou a nossa route table à subnet, ele cria uma rota default aqui para a nossa VPC. Deixa eu verificar aqui de onde que ele está pegando este cara. Então ele cria um internet gateway, nós podemos observar aqui que ele tem um internet gateway, enfim, ele abstrai a lógica aqui de criação de muitos recursos, tá? Nós temos mais subnet, se eu não me engano, nós temos uma subnet 2 aqui, uma public subnet e ele já fez a divisão aqui, ele já sabe qual é o próximo bloco, tá? E nós podemos verificar, nós podemos analisar aqui tudo que foi criado, tá? O NAT Gateway, ele cria também Private Subnet, então a lógica aqui por trás disso é que ele vai criar uma subnet pública e uma subnet privada em cada AZ, e ele vai dividir ali o nosso range de IPs, o nosso CIDR block, conforme nós especificamos lá na VPC, de forma igualitária entre todas essas AZs e essas subnets. Toda essa lógica é o próprio CDK que faz e eu não precisei especificar nada. Então nós vemos aqui que é um grande nível de abstração, muitos recursos são criados que pode ajudar bastante, que pode facilitar bastante o nosso desenvolvimento, mas que também nos limita quanto ao nível de customização que nós temos, ao nível de controle que nós temos. É claro que nós poderíamos customizar, nós temos propriedades aqui que permitem que a gente customize a criação dessas subnets, mas vai até um certo nível. Eu, por exemplo, não consigo definir aqui quais são os ciders blocks das subnets utilizando somente os construtores de nível 2, utilizando este carinha aqui. Para nós termos um nível de precisão, para nós garantirmos a customização como nós fizemos ali em Terraform, nós precisamos utilizar os construtores de nível 1. Então, eu recomendo que você dê uma olhada na documentação, não tem uma outra forma, não tem uma forma mágica de você entender isso, saber quando utilizar. Eu recomendo você começar utilizando esses níveis como a maior abstração, esses construtores de maior abstração, porque geralmente eles ajudam bastante, tá? E quando você precisar de customizar num nível mais baixo, aí sim, você pense em utilizar esses construtores de nível 1, tá? Mas eu já comecei aqui utilizando de nível 1 porque nós tínhamos um cenário mais específico, com um nível de customização maior. Beleza? Então eu espero que tenha ficado claro. Eu recomendo, de fato, que você dê uma olhada nessa documentação, porque vai agregar bastante. Espero que você tenha gostado. Vejo você na nossa próxima aula.