Hoje eu vou tentar fazer essa parada não ser tão longa quanto ontem, tá? Mas tem bastante coisa pra gente ver, pra gente discutir. Tô bem animado, tô trazendo algumas coisas bacanas. A gente vai falar bastante de protocolos de comunicação de forma geral, mas também eu vou trazer um pouco dessa parte de comunicação e protocolos para IA também. Então, acho que vai ser legal para a gente se atualizar e discutir também bastante coisa. IA, hoje em dia, é uma das coisas que mais gera dúvida e ficou pior que framework javascript que cada semana agora tem tem uma moda, tem um protocolo tem uma versão nova, coisa que funcionava não funciona mais e milhares de coisas teve um anúncio agora da OpenAI que está querendo comprar a Windsurf por 3 bilhões. Então, uma coisa é certa. A galera está querendo investir para o desenvolvedor ser mais produtivo. Agora, o ponto é, para esse cara ser produtivo, ele precisa entender de uma pancada de coisa. Já deu para perceber pelo bate-papo de ontem que... precisa entender de uma pancada de coisa, né? Já deu para perceber pelo bate-papo de ontem que eu acho que está muito longe de simplesmente a gente escrever alguma coisa para o código sair daquele jeito, né? Provavelmente tem muita coisa de background que tem que ser feita até o momento onde você pede para IA fazer realmente algo para você. A não ser que você esteja ali no Vibe Code, em um projetinho da padaria, aí dá pra fazer pelo Codex ou por qualquer Cloud Code, você não precisa nem olhar código fonte. Entendeu? Mas deixa eu contar uma história aqui pra vocês, pessoal. Eu queria que vocês sentissem e compartilhassem o meu sentimento comigo. Galera, abra as câmeras, por favor. Bora abrir essa câmera, galera. Vamos... Raramente... Tipo, não é daily de trampo que... Tipo, a gente fecha a cara porque tá todo mundo com cara de sono. Bota a cara aí e dane-se, meu povo. Bota essas caras aí, fica melhor pra gente interagir, fica um ambiente mais legal. Tem um monte de gente bonita aqui, ó, o Marcelo, o João, o Fábio a Ana, o Lucas, né tem gente que não é tão bonita, tem gente que é mais bonita, tô brincando, todo mundo tá super gatos hoje aqui e é bacana ver caras repetidas, né, de pessoas que vieram ontem e tão retornando hoje então, se tá retornando é porque de alguma forma aprendeu alguma coisa ontem e quer aprender mais coisa hoje, né? Mas, enquanto o pessoal tá chegando e tudo mais, preciso desabafar com vocês, galera. Preciso desabafar com vocês. Bom, obviamente, né, eu falo muito sobre o meu trabalho aqui na minha casa. E, obviamente, a minha esposa, ela tem ouvido a palavra, qualquer coisa que eu falo pra ela, no final eu adiciono no sufixo IA na frente. Entendeu? De tanto que eu tô mexendo com IA nos últimos tempos. A minha esposa viu o meu vídeo de vibe coding. E ela começou a pesquisar de vibe coding. Ontem à noite, depois da nosso bate-papo, fui tomar banho tava conversando com ela, ela falou será que eu consigo desenvolver uma aplicação pras crianças pra eu conseguir controlar a quantidade de leitura delas nas séries, onde elas ganham pontos conforme elas vão passando de fase, elas podem competir com outras crianças. Eu falei, como assim? Você quer que eu desenvolva? Não, não. Você acha que eu consigo fazer isso no Vibe Coding? Aí, cara, eu falei, meu Deus do céu, cara. A minha esposa tá querendo desenvolver software. Ela é pedagoga você entendeu? e eu não tenho dúvida alguma que de uma forma ou de outra, a tranco e barranco é capaz de sair alguma coisa, ela começou a perguntar que ferramenta que eu uso, o que que eu coloco e não sei o que, e blá blá blá eu vou pegar seu notebook, uma hora que eu tiver com o tempo eu vou dar uma olhada cara, virou um monstro aqui dentro de casa que eu... Saca? Então, se a minha esposa tá querendo, provavelmente daqui a pouco a esposa de vocês tá querendo, daqui a pouco o filho tá querendo. E uma coisa que a gente vai ter que aceitar de realidade é que vai sair um monte de software merda daqui pra frente a gente vai ter que dar conta de alguma forma desses softwares merdas mas o fato é que a gente vai ter muito programador não profissional no mercado e que eventualmente vai sair soluções e eventualmente esses programadores vão fazer alguns servicinhos bem repetitivos e babacas que nós desenvolvedores fazemos hoje e que se nós desenvolvedores fazemos hoje e que se nós desenvolvedores continuarmos fazendo esses servicinhos bem ruinzinhos, babacas com certeza a gente é limado entendeu? então somente o meu desabafo pra vocês que agora minha esposa quer virar programadora posso dar uma opiniãozinha aí Wesley? eu vejo isso muito bom eu vejo isso um movimento muito bom pra nossa área. Porque minha opinião é que isso vai trazer mais oportunidade em negócio. Porque esses programas, pra mim, eles vão nascer, mas com uma validade de uma empresa pequena. A partir do momento que essa empresa pequena, que tem um negócio, que fez uma prototipação de um sistema e botou ali no ar e a ideia deu certo, vai precisar reescrever isso de uma forma mais elegante, de uma forma mais profissional. E isso vai acabar trazendo mais sistemas para que programadores de verdade, vamos botar assim entre parênteses tenham mais oportunidade de negócio, isso é a minha opinião, porque pra mim eu vejo que é uma coisa muito parecida com o momento ali da pandemia a pandemia também trouxe um monte de programador merda pro mercado, mas isso faz tantos anos que esses programadores merda hoje em dia. Os caras não sabiam nada, cara. Hoje um programador de pandemia de 2020, o cara tem cinco anos de experiência, meu amigo. O cara já tá virando sênior. Entendeu? O cara era um cara que tava começando lá atrás e hoje em dia o cara, se ele estudou, se ele manteve o passo dele, cara, ele já é um profissional hoje. Tem muitas empresas que contratam um sênior com 5 anos. Eu vejo que o problema da IA é que a IA acho que vai dar menos oportunidade de aprender a programar do que o programador de pandemia, porque ele vai ter menos acesso ao código. Mas a questão de negócio, eu vejo que acho que vai ser bom. Cara, eu fico muito preocupado, cara, porque assim, é... Eu falei isso até num vídeo. Se você olha uma criança, ela vê dois buracos na tomada, ela enfia o dedo e toma choque, porque ela não tem ideia que aquilo é uma tomada. A gente sabe que é uma tomada desde 1950. Entendeu? Então, eles não têm noção do nível de consequências que aquilo pode sair gerando ali pra eles, entendeu? E isso aí é extremamente grave, o nível de software que vão ser gerados daqui pra frente, e obviamente a gente vai ter que resolver muita coisa. Vai abrir um mercado muito maior e os programadores novos vão estar em um nível de abstração muito diferente. Eu acredito que daqui a um ano, esses softwares de vibe coders aí, eles vão ter muito mais qualidade, inclusive. A data de validade deles vai ser um pouquinho mais para frente, inclusive. Entendeu? Mas problema grande, gigante, não tem como. Já dá para perceber só com o bate-papo de ontem que provavelmente a gente não vai conseguir trabalhar soluções grandes e importantes, críticas. A gente vai precisar não só de desenvolvedores, a gente vai precisar de gente boa. Porque desenvolvedor medíocre, aí a substitui. Isso aí acabou, entendeu? O desenvolvedor que é medíocre hoje em dia, aos poucos, esse cara ou ele vira muito bom e aprende ainda a trabalhar com IA, ou esse cara aí, entendeu? Rapidamente vai ser substituído pelo Daniel, que é um ótimo desenvolvedor, que estuda, fica até meia-noite estudando, aprende IA, é mega produtivo por cinco Daniels, que ele era antes, entendeu? E daí a empresa não vai precisar contratar o Joãozinho, tarefeiro, crudeiro de gira, porque o Daniel em um dia, ele vai conseguir fazer a tarefa de uma semana do cara crudeiro, né? Mas assim, galera... Tem uma coisa que é o saber a lógica do negócio, né? O desenvolvimento... É, cara. Cara, desenvolvimento é um troço complexo pra caramba. Entendeu? O fato é que alguém tá gerando código maluco por aí. E agora a minha esposa... O ponto... Eu acho que a maior provocação aqui é que, de uma forma geral, num lado bom, lado ruim, a programação está virando mais acessível, de uma forma muito mais forte e massiva e a gente não sabe o que vai acontecer no futuro. O que eu tenho absoluta certeza, tá? Oi! Você acha que vai chegar uma hora que talvez as empresas, ela, por exemplo, você vai ter projetos desenvolvidos porque com a produtividade da inteligência artificial por exemplo, você tem um requisito lá então você pega esse requisito e joga lá no Gemini ou no chat de PT, aí com esse requisito hoje tem plataformas onde você consegue desenvolver um projeto em Next por exemplo, um front-end. E aí você consegue trazer esse front-end para o seu GitHub. Aí você tem o GitHub. No GitHub você tem o Copilot, onde você utiliza a inteligência artificial do Copilot ali e ele consegue corrigir qualquer coisa que automatiza ali. Então vai chegar uma, a minha opinião, vai chegar uma hora que as empresas, você vai desenvolver projetos e você vai entregar projetos prontos para a empresa e só vai ter que ter aquele desenvolvedor ali onde ele consiga fazer a manutenção mensal de um... Então, cara, isso depende muito. Se o projeto é simples, cara, isso depende muito. Se o projeto é simples, cara, isso já dá pra fazer hoje, tá? Agora, obviamente, eu não quero botar isso na conta do Instagram, entendeu? Mas, por exemplo, se a gente fosse fazer, entre aspas, um Instagram que não fosse pra ter milhões, mas utilizando, basicamente, aquele system design que a gente fez com certeza não é um desenvolvedor só não é um cara simples ali que vai manter entendeu? São coisas bem complexas processo de comunicação, processo de segurança tem muita coisa por trás de software grande que vai além do código, acho que o grande ponto que todo mundo tem que se ligar hoje em dia aqui não é mais o código. O código em si não vai ter mais valor que tem hoje. O código vai ser detalhe. Ponto. Deixa eu te fazer uma pergunta. Tu acredita que a gente está tratando hoje mais é uma questão de escala e de solução. Eu trabalho hoje com uma das maiores empresas que existe no mercado de consultoria e desenvolvimento. E eu vejo que a IA é uma realidade. O uso dela em diversos pontos, em diversas camadas, em todo o processo. E eu vejo que o que ela está fazendo, ela vem substituindo, de certa forma, em um ponto aqui ou ali, mas ela se torna muito mais um catalisador e um funil também, para que se escale. Que se um funil também para que se escale, que se escale em tempo que se escale em qualidade que se escale em inovação concordo em mil por cento o único ponto é que quando você, tá, user seu nome está aqui como user ah ok, Leandro quando Leandro quando Leandro ent Quando o Leandro entende muito bem desenvolvimento, arquitetura de software, arquitetura de solução, o Leandro entendendo direito e a ele vai fazer o que o Leandro faz hoje cinco vezes mais rápido. Ponto. Você vai valer por cinco, meu amigo. Se você comparar você com você mesmo. O ponto é se um Leandro que era cinco hoje entrega cinco vezes mais, será que eu preciso contratar outros Leandrinhos? Já que você consegue ter uma produtividade muito maior? Vai depender muito do mercado. Se uma empresa está em alta expansão, ela vai contratar, contratar exatamente para chegar nesse ponto ótimo. Agora, o mercado da forma como ele está, você acha que há chances de a gente sair contratando mais gente hoje ou deixando de contratar? Sim, deixando de contratar. Isso já é um fato, já tem número na realidade. Um monte de empresa já falou, eu não tô contratando mais Eu tenho empresas que falam pra mim Não é empresa, eu tô falando de empresa grande Gente que é diretor de empresa grande, não posso falar o nome da empresa Que falou, cara, um A gente não tá contratando mais júnior, acabou o júnior aqui Entendeu? Enquanto a gente não decidir como é que vai ser o novo plano de carreira de um Júnior a gente não tá contratando Júnior exatamente isso que eu ia que eu ia entrar na questão assim né tu não acha que não vai acontecer em vez disso uma diferença do processo de evolução de um programador com certeza eu tenho outro negócio cara tem um banco famoso eu não vejo morrer profissões. Eu vejo alterar a profissão. Por exemplo, a tecnologia sempre alterou e quem se atualizou continuou empregado e até trouxe mais posse de trabalho. Tipo, datilógrafo. Datilógrafo, lá com a máquina de escrever, escrevia lá. Teve que aprender a ligar o computador, abrir o Windows, abrir o Word pra virar digitador. Então teve uma migração. E aí apareceram outras profissões, sei lá, o cara que ia imprimir, o cara mexer com impressora, manutenção de rede, sei lá. Então surgiram mais postos de trabalho que o datilógrafo. Então talvez o programador júnior não vá se transformar num cara responsável por escrever os os os caras eu entendo o negócio que você tá querendo fazer documentação então vai ser responsável por documentar o sistema alguma coisa ponto, cara. Hoje já saiu um novo posto de trabalho. Esse é o ponto, cara. A gente está num momento... Cara, e essa parada de prompt, cara, é um mundo. Depois eu posso mostrar para vocês, cara. É um mundo que... Nós, desenvolvedores, incluindo eu, mas eu consegui me vacinar. Não estou dizendo que todos estão vacinados. Mas eu tinha três pressupostos. Um, que eu sabia trabalhar com IA, porque eu tinha a minha ideia, o Copilot, pedir, ele mexia os arquivos, etc. Esse era um pressuposto. Outro pressuposto que eu tinha é que a gente fala em prompt engineering, etc. E isso, o importante é saber pedir pra IA. Mas eu achava que eu sabia pedir, sei lá. Eu sabia, ok. Beleza? E a outra coisa, eu achava que eu sabia realmente trabalhar com IA. Entendeu? E quando eu percebi que eu não sabia nada de prompt, quando eu percebi que eu não sabia realmente programar com IA, quando eu percebi que tinha um monte de coisa que eu não tinha ideia que entrava num processo de desenvolvimento com IA, eu simplesmente falei eu não sei trabalhar com IA, ponto o que eu tô fazendo aqui é brincar de conversar com o chat GPT ou com o cursor, pedindo pra ele corrigir um bug e fazer um teste ali pra mim, mas nada algo realmente substancial que vira o jogo, entendeu? E, cara, depois que eu, assim, mergulhei, mergulhei, mergulhei, eu consigo ver eu antes e depois e o ponto é que essas coisas estão acontecendo tão rapidamente que a nossa profissão, ela tá sendo redefinida. Os cargos, como é que é? Eu conheço empresas, bancos grandes, estão falando, a gente está fazendo algo chamado juniorização. A gente está contratando agora sênior como júnior. Entendeu? O cara é sênior, a gente fala que ele é júnior, baseado no conhecimento dele. O cara que é staff vira sênior. Estão descendo esses degraus. Cara, não dá pra saber o que vai acontecer com o mercado. Na real, eu não tô nem pensando muito em futurologia. O que eu penso, que eu tenho certeza, se eu entender bem de desenvolvimento de software, desenvolvimento de arquitetura, e conseguir desenvolver muito bem de verdade o Zanyar, eu tô garantido, eu tô na minha, eu tô seguindo o fluxo. Eu não vou ser o cara do datilografia que não aprendeu a mexer no computador, entendeu? É basicamente isso. O que eu acho que todo mundo tem que se garantir é isso. Ter fundamento técnico muito forte, manjar de arquitetura de software, de solução, manjar de entrega de software, manjar de todas essas paradas de verdade e, obviamente, conseguir aliar tudo isso aí. Eu acredito que quem faz isso hoje consegue ser mais produtivo, aprender mais e tudo mais, garantir mais, provavelmente, inclusive, até ganhar mais. Porque esse tipo de profissional vai ser cada vez mais difícil de encontrar. Caras bons de verdade, que saibam usar com IA de verdade e que consigam substituir, sei lá, cinco desenvolvedores, se substituir cinco vezes em relação à sua própria produtividade. Para não dizer que eu estou substituindo outro cara, para a produtividade, para não dizer que eu estou substituindo outro cara, para não ser tão agressivo assim. Mas, hoje o nosso ponto, a gente vai falar de A hoje, a gente acabou esquentando e conversando, fugindo um pouco do tópico do nosso bate-papo, mas a gente vai falar um pouco de A hoje, eu vou trazer um pouco de... A gente vai falar bastante hoje sobre comunicação entre sistemas, resiliência entre sistemas. E essas paradas são uma das coisas mais importantes para que a gente consiga desenvolver qualquer tipo de sistema. Vide as tecnologias que a gente acabou trabalhando ontem no System Design lá do Instagram. E, pelo amor de Deus, principalmente para quem não... para quem não participou ontem, eu estou tentando deixar bem claro, o nosso objeto aqui não é ficar delirando e falando que a partir de hoje todos nós vamos criar o Instagram. Pelo amor de Deus, tá? Não sejam inocentes e saibam que eu não sou inocente o suficiente. O mais importante de tudo que a gente está fazendo aqui é conseguir trazer problemas para a gente resolver ter casos específicos que a gente vendo aquilo a gente consegue trazer isso para o nosso dia a dia quem aqui ontem baseado no que vocês aprenderam conseguiu ter algum insight que você vai poder trabalhar na que você vai conseguir trabalhar ou trazer para a empresa que você vai poder trabalhar na... que você vai conseguir trabalhar ou trazer pra empresa que você tá trabalhando. Hoje em dia, alguém conseguiu ter algum insight? Wesley, uma coisa que a gente usa muito nesse esquema de escalabilidade aí, jogando redis e tudo, acho que a grande maioria das pessoas se não passaram, vão passar por isso. Pelo menos quem trabalha com comércio, cara, é Black Friday, né? Ah, cara, demais. Tem que encargá-lo ali e você precisa ter resiliência, precisa ter disponibilidade. O lance de tudo isso, cara, na real, sabe o que que é? É que todo mundo fala que o importante é ter cash e saber bater no cash, mas eu acredito que depois de ontem, talvez dê pra ter dado uma visão um pouco diferente de quão complexo é trabalhar com cash, né? Fez sentido o que eu tô querendo dizer? Principalmente quem participou ontem. Dá pra perceber que trabalhar com cash o buraco é muito mais embaixo do que você dar um 7 e um get numa chave que você botou lá no Redis. A gente tem muitas estratégias que a gente consegue trabalhar junto com o cache. A ferramenta de cache guarda as coisas na memória. As estratégias que você usa para trabalhar e conseguir alivar o gargalo é outro mundo. Então, ontem a gente falou de Fanalton Reading, Fanalton Write, a gente acabou falando também de Sorted Set, falamos de Sorted Set, provavelmente o Sorted Set pra pegar as paradas de forma cronológica, a gente acabou mostrando comandos e coisas desse tipo, depois se sobrar um tempo a gente pode até dar uma mini aula de Reds aí para vocês, mas não sei se a gente vai conseguir ter esse tempo. Mas saiba que a gente vai ter isso no nosso MBA. Então, vocês, por favor, deem uma olhada no nosso programa de MBA, que você vai poder entrar na pré-venda com um baita desconto e conseguir estudar bastante sobre todos esses diversos assuntos aí. Galera, eu vou compartilhar minha tela aqui para a gente começar, vamos dizer assim, um pouco mais oficialmente e seguindo as coisas. Você me permite 30 segundos de fala? Tem que ser 30, cara. Tem que ser 30 enquanto eu compartilho, beleza? Tem que ser 30, cara. Tem que ser 30 enquanto eu compartilho, beleza? Eu comecei a trabalhar na década de 80, na década de 90 eu passei pelo boom das ferramentas case, onde se prometia tudo isso, de programador não ia ter utilidade, código não ia ter utilidade, junto com isso veio o Visual Basic, por exemplo, que você ia programar só visualmente daí para frente, a promessa era essa. E não foi bem isso que aconteceu. Foi necessário que eu me reciclasse, assim como todo mundo que ficou no mercado. Muita gente saiu, passou a vender equipamento na época, parou de trabalhar como programador. Depois disso, teve várias outras reciclagens para trabalhar com web, trabalhar com SOA, microservice. E a, para mim, é só mais uma reciclagem que eu estou fazendo. Cara, eu concordo com você. Foi muito importante o que você falou do System Design, por exemplo, que pra mim me parece que é uma referência importante pra poder trabalhar com o IA hoje, né? E só pra concluir aqui, nessa reciclagem que eu tô fazendo, eu já me inscrevi no MBA e tô aqui de volta com você por isso, porque esse é o cara. Escutem o que esse cara tem pra falar tô brincando cara, eu concordo com você eu passei por muitas dessas fases eu comecei a programar a brincar de programar no final da década de 90 e comecei profissionalmente no início de 2000 eu peguei a bolha das startups e a bolha da internet quebrando eu comecei a mexer com startups e a bolha da internet quebrando, eu comecei a mexer com o Pascal, depois eu fui pra Delphi daí teve toda aquela parada, agora é só agora é só arrastar botão e tinha um programador programação orientada a botão começou a ter todos esses esses tipos de coisa vocês estão vendo a minha tela, né? mas cara o que eu sinto hoje, honestamente é que a parada mudou com a IA entendeu? a parada com a IA ela é mais muito mais pesada essa transformação que a gente passou ao longo dessas décadas aí, a IA ela tá sendo um marco, eu acho que 10 vezes, 100 vezes mais forte do que essas revoluções que a gente teve nas criações das ideias, nas ferramentas, nos frameworks, nas camadas de abstração, na parte de cloud computing, etc, etc. Eu acho que o buraco da IA vai ser mais pesado e vai ser uma disrupção muito mais forte do que foi, e eu concordo com você claramente que a nossa profissão mataram a gente várias vezes já, né? E a gente não coisou até agora. E, na minha opinião... O último argumento? Foi, claro. O último... Estou instalando energia solar aqui em casa. E eu prefiro contratar um profissional para instalar do que eu mesmo fazer. Eu tenho a parte de conhecimento de eletricidade para isso, de eletrônica para isso. Eu mesmo comprei os equipamentos para poder fazer, para sair mais barato. Mas eu não me arrisco a instalar, porque eu prefiro um profissional instalando. Cada detalhezinho que o profissional sabe, que eu não sei. Eu prefiro um profissional instalando. Cada detalhezinho que o profissional sabe, que eu não sei. Eu acho que sempre vai ter espaço para profissionais no mercado. E sempre vai ter gente fazendo gambiarra no mercado. E isso é o que eu acho. Eu concordo absurdamente. A única coisa que é o meu ponto de reflexão e, novamente, eu não consigo fazer a futurologia, é que a partir de agora desenvolvedor bom de verdade que tenha na mão, vai valer por cinco desenvolvedores médios que a gente tinha. Entendeu? Esses cinco médios aí, eles vão para onde? Ou como que vai ser a evolução desses caras? Como é que vai ser a entrada de novos profissionais no mercado? Com a competitividade tão grande, né? Como que um cara que é júnior e não sabe nada, vai conseguir entrar numa empresa já sendo tão produtivo quanto um júnior cara, basicamente um cara que é júnior, já tem conhecimento sólido de programação ele vai ter produtividade de um pleno hoje em dia, entendeu? então, vamos mudar de assunto, galera. Senão a gente vai falar só sobre isso. Wesley, uma coisa também. A IA deu muito poder para quem já é programador, para quem já desenvolve, já faz projeto. Porque antigamente, sei lá, você tinha um projeto engavetado ali que não conseguia tocar para frente porque não tinha tempo e tal. Hoje em dia você consegue tocar. Aqueles caras de back-end que odeiam front-end estão felizes da vida. É, pô. Cola o filho, mas sai o front-end. Agora, o resultado que sai lá atrás, meu amigo, aí eu não quero nem pensar. Entendeu? É mais ou menos o cara de front-end que manda gerar o back-end da parada. Mas é o que é. Pessoal, vamos focar agora aqui. Pessoal, somente para não deixar passar, tá? Importante vocês saberem, escaneiem esse QR Code. Esse QR Code vai fazer você cair numa página, que eu vou pedir para coloarem aqui no chat para vocês. Essa página deixa eu vou pedir para colarem aqui no chat para vocês. Essa página deixa eu pegar aqui essa página ela vai dar para vocês o acesso a esse formzinho aqui. Esse form você preenche aqui esses dados a A nossa equipe vai entrar com você. Muitas vezes eu entro em contato também para fazer um bate-papo, para entender como está a sua vida hoje. Qual é o momento profissional? Que cargo você é? Onde você trabalha? Como está a sua disponibilidade de tempo? Quais são os seus objetivos futuros como desenvolvedor e tudo mais? Baseado nisso, a gente conversa com vocês e explica e verifica se é o momento correto de você entrar nesse programa que a gente tem do nosso MBA em arquitetura. Esse nosso programa do MBA, ele é um programa reconhecido pelo MEC, que a gente tem uma própria faculdade. E o grande foco dele aqui é arquitetura de soluções, arquitetura de software, DevOps SRE e soft skills. A nossa ideia aqui é que realmente você seja capaz de liderar, arquitetar e desenvolver soluções de grande porte em grande empresa. Então, basicamente, pessoal, o que eu digo aqui pra vocês é, se você quer trabalhar em empresa grande, em projeto grande, fazer coisas, tá? Muito com desafios realmente bem além do que normalmente a gente cai naqueles softwares bem padrão de prateleira, esse MBA ele vai te dar exatamente a base que você precisa para isso. Tudo que a gente colocou aqui nesse MBA foi baseado num estudo muito, muito forte que a gente fez com todo mundo da minha rede de contato, dos caras que trabalham nas grandes empresas, os professores que dão aulas também, são somente gente ali gabaritada, a gente tem participações especiais. A gente tentou pegar, por exemplo, a gente vai falar de Solid, vamos fazer uma talk com o Uncle Bob. A gente vai falar de arquitetura hexagonal, vamos fazer uma talk com o Alistair Coburn, que criou arquitetura hexagonal. Vamos falar em domain driven design, vamos fazer uma apresentação do cara aqui, do Van Verno, que criou o livro de Domain Driven Design. Então, o nosso principal ponto aqui do MBA é realmente conseguir fazer você liderar, entender de arquitetura de software, entender de arquitetura de solução, entregar software, manter softwares com níveis altos de confiabilidade, porque começa a entrar na parte de SRE. E uma coisa importante também aqui é que muito do que a gente está participando agora aqui no Zoom, o nosso programa é muito parecido. A gente tem as aulas gravadas, que você assiste no seu tempo, mas nós temos esses encontros. E esses encontros, eles têm categorizações diferentes. Então, tem encontros onde a gente chama pessoas muito boas, para não falar um português feio, que raramente a gente teria acesso para conseguir ver uma talk dela, trocar ideia com ela, ou ela te dá uma sessão de mentoria. A gente tem sessões de mentoria de carreira e mentorias técnicas, que a gente entra aqui e passa três horas no Zoom, tirando dúvida, discutindo, dando direcionamento pra galera. É incrível como a gente vê que às vezes a gente vai tirar dúvida técnica e a galera fala acabei de me treinar, me botaram como tech lead, o que eu faço agora? Por exemplo, isso é alguma coisa bem comum que a gente acaba vendo também. Então a gente tem essas dinâmicas em grupo, esses breakout rooms, a gente tem lives com especialistas, né a gente foca muito nessa pessoalidade, galera, o que vocês estão vivendo aqui nesses dias é muito parecido com o que é o programa no dia a dia além de você ter acesso a nossa plataforma, onde você vai assistir as aulas que vai dar a base pra você participar dessas ao vivo e obviamente que essas aulas ao vivo, elas ficam gravadas pra você assistir depois, inclusive caso você não possa ter participado ao vivo, tá? Então, pessoal, deem uma olhada com carinho, tá? Escaneiem esse QR Code, aqui tá o site do MBA também, eu vou pedir pra colocar, tá? Os encontros são semanais, dependendo, a gente pode ter dois encontros por semana, mas às vezes pode ter uma semana específica que a gente não tem um encontro. Depende muito da agenda, vocês têm uma agenda onde a gente consegue seguir. Mas eu acho que a grande sacada está fazer networking, conhecer outras pessoas, ter acesso a pessoas que normalmente você não teria. Então, a gente traz gente da Google, a gente traz gente da ThoughtWorks, a gente traz gente de grandes bancos, a gente traz gente de sei lá, desde mercado livre desde empresas fantásticas, grandes aí de cloud, gente da Microsoft, gente da Google então graças a Deus, durante todos esses tempos, eu consegui criar uma rede de contato muito boa com pessoas que eu gosto demais. E essas pessoas começam a abrir portas e essas portas a gente consegue abrir essa porta diretamente para você, para você estar junto com essas pessoas. Então, a gente foca muito nessa pessoalidade. Hoje em dia, a gente está muito solitário, galera. A gente e o chat GPT tirando dúvida com ele. E tem muita vida além disso, né? Olhando as caras, tirando dúvidas, discutindo. Então, recomendo que vocês acessem, escaneiem esse QR Code ou cliquem ali no link aí embaixo. Eu não sei mandar mensagem no chat eu quero mandar pra everyone e o Zoom me escolhe pra eu mandar pra mensagem direta, eu tenho que aprender a mexer com o Zoom, cara eu não sei mandar pra todo mundo tá, mas o o Leonan ali, deve fuçar e comandou o link cliquem nesse link aí no chat, tá sem compromisso senta com a gente, bate um papo a gente faz vários bem mandou o link, cliquem nesse link aí no chat, tá? Sem compromisso, senta com a gente, bate um papo, a gente faz vários bem bolados de valores e coisas desse tipo, acho que a gente tá com 3 mil reais de desconto nessa pré-venda. Então, entrem em contato aí, somente pra gente ter o nosso momento jabá, não tenho dúvidas que vai ser uma experiência aí fantástica pra vocês. Beleza? Galera Então Hoje a gente vai falar Sobre Comunicação entre sistemas Resiliência Protocolos de comunicação Ontem a gente Somente pra gente Dar um recap aqui Do que a gente falou ontem Se vocês perceberem O system do que a gente falou ontem. Se vocês perceberem, o System Design que a gente tem, ele trabalha muito com comunicação. Se vocês perceberem, aqui eu tenho chamadas síncronas que eu posso resolver, eu tenho um cara que roteia, eu posso fazer uma chamada síncrona, eu posso trabalhar, eu tenho um cara que roteia, eu posso fazer uma chamada síncrona, eu posso trabalhar com filas, eu posso, eventualmente, trabalhar com outros tipos de protocolo que eu tenha conexão persistente, eu posso realizar conexões e chamadas desde bancos de dados, chamadas em cloud, a parte de disponibilidade global, a parte de disponibilidade global, a parte de edge computing, a gente tem muita forma de a gente se comunicar. Qual é o panorama que eu vejo hoje? E eu não estou dizendo aí para vocês que todos passam necessariamente por isso, mas eu vejo, com a experiência que eu tive nesses últimos tempos, dando muita aula, participando de muitas dessas sessões é que a grande limitação que nós temos na hora de a gente desenhar um sistema é que a gente não sabe as possibilidades de protocolos e meios de comunicação que a gente tem e aí quando a gente entra nesse ponto a gente começa nesse ponto, a gente começa a ficar limitado a algo chamado REST. Fala a verdade, galera. Fala a verdade. Eu não estou dizendo que você só sabe trabalhar com REST mas que isso aqui muitas vezes vira muleta pra gente fazer com que sistemas sejam feitos muito de uma forma mecânica o REST virou a nossa principal bengala. REST é vida e REST, no final das contas, é a nossa muleta. É óbvio que se a gente trabalhar, fazer essas comunicações, trabalhando com REST, etc., é super útil, é padrão do mercado. Então, é comum isso acontecer. O problema não está com o REST. O problema é não entender as categorias e contextos que a gente tem para trabalhar com comunicações entre sistemas que vão muito além do REST. É aquela história. Se eu sei que existem 10 ferramentas, ou 10 protocolos, na hora que cair um problema para mim, eu vou levar em consideração todos esses protocolos e, eventualmente, eu posso acabar no REST. Mas eu tenho a possibilidade de poder ver opções que façam mais sentido naquele momento. Então, isso aí é o grande ponto. O problema não está no REST. O problema está em a gente não saber as outras opções que muitas vezes poderiam cair naquele contexto muito melhor que o REST. E lembrando, pessoal, a arquitetura de software e a arquitetura de solução não está em definir uma tecnologia. Está, muitas vezes, em definir diversas estratégias de tecnologias dentro de um ecossistema. Ontem a gente teve o caso, que eu estava falando com vocês do Fanaution Read, e daí em seguida vocês já falaram, e no caso do Neymar? Opa, então vamos trabalhar de uma forma híbrida. De um jeito, a gente trabalha assim, do outro jeito, a gente trabalha assado. O problema muitas vezes que eu vejo nos sistemas que a gente desenvolve, a gente está muito no 8 ou 80. O que que isso significa? Ou é REST, ou é aquilo. Ou é isso, ou é aquilo. Por que não a gente pode ter composições de protocolos e formas de comunicação que garantem mais flexibilidade e claramente resiliência, tá? E antes de eu iniciar a falar desses protocolos, dos tipos, as categorizações que eu vou trabalhar aqui com vocês, eu queria fazer uma pergunta que alguém poderia me responder, tá? O que, na opinião de vocês, é resiliência? Escrevam aí no chat, galera. O que é resiliência? A opinião de vocês. O Elias tá com a mão levantada por primeiro. Elias, se quiser dar a sua visão do que é resiliência o que é resiliência pra você, cara? é uma pergunta filosófica, né? assim, resiliência pensando em pensando no contexto de software tá? eu acho que é meio que manter a saúde da vizinhança e a vizinio que manter a saúde Da vizinhança e a vizinhança Manter a sua saúde, entendeu? Acho que você fala isso Nos seus vídeos, nas suas aulas Do Fullstack, do Fullcycle Que Cara É você Se blindar De Qualquer interrupção, qualquer ponto de falha específico ou genérico. Pode ser, por exemplo, um problema no Kafka. E o Kafka vai parar a sua infraestrutura inteira. parar a sua infraestrutura inteira se acontecer algum problema no Kafka, já era a sua empresa um milhão de reais, aquela mensagem que valia um milhão de reais, você perdeu então a resiliência são formas de você garantir que não vai acontecer isso né, e assim, é um ponto de vista mas... Cara, eu acho que tá muito dentro e eu tô vendo várias mensagens aqui no chat que a galera tá mandando, ó. O Alex colocou, resiliência é se manter firme independente do problema. Resiliência é se manter funcionando, mesmo que tudo dê errado e até a energia da AWS acabe, né? O Marcelo colocou que resiliência é tolerância à falha. A capacidade de tentar várias vezes, mesmo quando encontrar falhas. Então, acho que a gente está indo mais ou menos no mesmo caminho. Normalmente, eu faço um desenho, inclusive, nas palestras, às vezes, que eu dou sobre resiliência entre aplicações de grande porte. Normalmente, eu dou um exemplo de uma árvore. E o que acontece? Eu começo a receber várias jarradas de vento aqui para mim. Todo mundo tentando mandar rajada de vento aqui nessa árvore. Essa árvore tem duas opções. Ou ela se mantém firme, mas a força que ela vai receber aqui vai fazer o que que ela faça o que quando ela fica muito firme aqui ela vai quebrar, ponto se eu tentar ficar firme eu vou quebrar a resiliência no final das contas ela permite que a gente se dobre e tente se adaptar à situação que a gente está e conseguir manter ao máximo a nossa capacidade de entregar resposta. Ou seja, a resiliência é algo que faz com que a gente faça o máximo possível em circunstâncias adversas. E quando eu falo em garantir resiliência ou ter resiliência no meu sistema, eu estou querendo dizer o quê, no final das contas? Eu estou dizendo é que se o meu sistema não prever resiliência, significa que esse meu sistema pode não atender os requisitos e fazer com que ele agregue valor no negócio. Nosso amigo deu o exemplo do Kafka, mas vamos fazer um exemplo bem simples aqui. Eu tenho um serviço A, eu tenho um serviço B, eu mando um request para fazer uma compra para esse cara aqui. No momento que eu fiz esse request usando o REST aqui, o que aconteceu? Esse cara estava fora do ar nesse momento. Deixa eu colocar esse cara verdinho. Esse cara estava fora do ar e o que acontece aqui nesse momento? Eu perdi essa mensagem. Como que eu garanto resiliência nesse caso? Deu ruim, esse cara está fora do ar. Como que eu não me enrolo? Porque? Deu ruim, esse cara tá fora do ar. Como que eu não me enrolo? Porque eu sou o responsável por fazer a compra. E o comprador não tá lá, é o se vira nos 30. Então, resiliência, a gente começa a pensar em técnicas de como prever ou proteger o nosso sistema de situações que a gente pode ter disponibilidade e principalmente perda de dados e a gente consegue perceber que há diversos casos que a gente tenta minimizar riscos mas não necessariamente esses riscos eles não vão existir, muitas vezes o negócio exige que você faça algo desse tipo e que se esse cara estiver fora do ar, realmente você vai perder o negócio. Existem situações que a gente precisa disso. Infelizmente. Às vezes eu preciso muito mais de consistência do que disponibilidade. Então, nesse caso, eu vou ter indisponibilidade por conta que eu não tenho dados consistentes. Então, eu vou perder informação ou vou perder uma oportunidade de negócio aqui. Então, quando a gente está falando em resiliência, é realmente a gente conseguir se adaptar a qualquer tipo de falha, mas não somente se adaptar a como que a gente vai se comportar em caso de falha. E por que que é importante a gente falar sobre esse assunto? Porque quando eu estou falando em comunicação entre sistemas, naturalmente eu falo sobre resiliência, porque cada protocolo de comunicação tem sua característica e baseado nessa característica, a gente pode ter mais ou menos resiliência, a gente pode ter mais ou menos confiabil. A gente pode ter mais ou menos confiabilidade. A gente tem prós e contras. E para isso, a gente precisa categorizar. Galera, eu não sei como é que funciona a mente de vocês, tá? Mas a minha mente, ela funciona muito quando eu consigo ter a estrutura de algo na minha frente para eu conseguir entender. Quando alguém fala comigo em categorias, em tópicos, em subtópicos, eu fico uma pessoa muito menos ansiosa, porque eu tenho a sensação que estou tendo uma visão do todo, e não somente daquele detalhe. Então, normalmente, quando eu tento passar coisas desse tipo, eu gosto de tentar categorizar para você conseguir entender qual caso de uso serve para cada determinado tipo de situação. Então, acho que esse aí é um ponto importante. Então, eu vou trazer aqui. A gente vai começar com pontos básicos e depois a gente vai avançando com outros pontos um pouquinho mais complexos ou fora da caixa ou que são menos usados. Mas, novamente, não é porque é menos usado que você, no futuro, não vai poder ter um caso de uso que você vai trabalhar com esse cara, tá? Então, lance o seguinte, tá? Nós temos um tipo de comunicação síncrona, né? Ou seja, você faz uma requisição e você necessita da resposta de forma imediata. Uma forma mais clara de a gente falar de requisição síncrona é o nosso grande e forte REST. Mandei um request, espero um response. Certo? Ou seja, os envolvidos precisam estar online. De forma geral, com a comunicação síncrona, aos precisam estar online. De forma geral, com a comunicação síncrona, a gente tem que estar online. Eu estou falando agora com o Anderson, com o Clã O'Newton, com o Elias, com todo mundo, e eu consigo falar e você consegue responder. Você tem que estar online aqui no Zoom para você conseguir falar comigo nesse momento. Em determinados contextos, a comunicação síncrona custa mais caro. E eu vou explicar o porquê que comunicação síncrona custa mais caro. E se o servidor estiver fora, há possibilidade de perda de dados. Alguém consegue me dar um exemplo por que comunicação síncrona muitas vezes custa mais caro? Pode falar aí, Clonius. Taca a mãozinha levantada. Consegue dar um chute aí pra gente, cara? Bom, boa noite. Wesley, já vi diversos vídeos seus rapaz, você é um monstro na programação, viu obrigado eu vou ter a oportunidade de conhecer a fundo no MBA que vou participar, com fé em Deus show de boca quanto a sincronização a comunicação assíncrona o serviço tem que estar ativo. Então ele vai estar computando a nível de custos. O exemplo é esse. E a assíncrona não. A assíncrona é só sob demanda. Eu vou dar um exemplo aqui. Por que comunicação síncrona custa mais caro? Tá? Vamos imaginar que nós estamos no supermercado, tá? Eu tenho os meus caixas aqui, certo? Os caixas que vão atender agora aqui a gente. Eu tenho quatro caixas aqui, nesse momento aqui pra mim. caixas aqui, nesse momento aqui pra mim. Se eu tenho oito pessoas querendo passar a compra, o que vai acontecer nesse momento? Quatro pessoas vão ficar sem resposta. Tô sendo dramático, né? Óbvio que eu tenho um servidor web que consegue receber requisições e tudo mais, mas no final das contas, ele responde uma de cada vez, né? Você cria vários forks e tudo mais, mas vamos pensar de forma bem primitiva. Se eu tenho quatro caixas e eu tenho oito pessoas, significa que, em tese, eu deveria conseguir atender simultaneamente essas oito pessoas. Tá? Essa que é a grande verdade. A grande verdade é que se eu tenho oito usuários, eu deveria conseguir atender os oito simultaneamente. Isso é a comunicação síncrona. A gente está falando no Zoom e todos estão podendo falar, se comunicar 100% nesse momento em tempo real. Essa comunicação é síncrona e ela custa caro, porque ela tem que garantir disponibilidade muito forte aí nesse caso. Agora, vamos imaginar que eu tenho um supermercado, eu tenho quatro caixas e eu tenho duas pessoas. O que acontece? Eu tô gastando mais dinheiro porque não tem gente suficiente. Eu tenho mais que quatro pessoas, eu perco o cliente. Entendem qual que é o grande problema da comunicação assíncrona? Você tem que ter altíssima disponibilidade de atender simultaneamente essas pessoas. E por isso que custa caro. Toda vez que você quer atender todo mundo ao mesmo tempo, custa mais caro. Ponto. E a comunicação assíncrona nos força a fazer isso. Aí vocês devem estar pensando, poxa, mas eu consigo subir um NGINX que consegue com computação e etc. atender vários usuários. Acredite, ele não está necessariamente atendendo vários usuários. Ele está atendendo um usuário de cada. E esses caras estão entrando numa fila interna do NGINX da vida. Ele pode ter workers para tentar paralelizar, mas o ponto é, tá? Eu não consigo atender todo mundo simultaneamente. Ou, se eu consigo, eu pago preço para fazer isso. Ok? A comunicação síncrona é esse o comportamento dela. E não tem nada de errado com isso. Porque eu conseguir fazer coisas em tempo real para mim, muda o jogo. Eu falei ali com o Elias e ele me respondeu. Ele não teve que me mandar um e-mail e eu ficar esperando 10 horas depois o resultado daquilo que ele colocou. Então, nesse caso, a comunicação síncrona tem todo o seu valor e existem casos, e grandes partes dos casos hoje em dia, se a gente não tivesse ou trabalhasse com comunicação síncrona, a gente não conseguiria ter a experiência que a gente tem com a web. O ponto é a gente entender prós e contras. E, pessoal, sempre coloque isso na cabeça de vocês. Se você escolhe uma tecnologia, uma forma de comunicação, um protocolo, qualquer decisão técnica que você for tomar, que você não saiba as desvantagens dessa decisão, provavelmente você não está pronto ou você não deveria estar tomando essa decisão. Se você não sabe o risco que você tem de implementar uma determinada situação, você não tem noção do risco e o quão isso pode custar caro para a sua empresa. E um ponto importante para a gente ser observado aqui, pessoal. Tudo que eu estou falando, eu estou pensando em aplicações grandes. Eu estou pensando que você trabalha em um grande banco, em um grande varejo, que você trabalha em uma consultoria que tem projetos cabeludos. Eu não estou falando aqui para pequenos projetos. Talvez você hoje esteja trabalhando em um pequeno projeto, mas eventualmente você vai conseguir um emprego, vai trabalhar em grandes empresas então o que eu estou falando aqui não é para você trabalhar no Instagram que nem o nosso amigo falou ontem que muito que a gente está ensinando nunca vai usar porque a gente nunca vai trabalhar em sistemas com milhões de usuários não necessariamente, tem muito do que a gente usa, pode ser aplicado em sistemas grandes. Tudo que você vai ver na Full Cycle, de forma geral, são sempre focados em aplicações de grande porte. Que é esse, é o gás que a gente quer separar você no mercado. Não para você ficar fazendo site no Wix, basicamente. Então, essa é a característica da comunicação síncrona. Eu tenho a outra característica do outro tipo básico aqui de comunicação que inclusive o meu amigo lá já estava dando spoiler que é a comunicação assíncrona. A comunicação assíncrona, ela não precisa estar conectada ao mesmo tempo para trocar informações. A mensagem foi enviada. A mensagem foi enviada. Demora ser uma análise de negócio do que é aceitável. O que eu escrevi aqui? Demora, por exemplo, se for uma análise de negócio, se for uma análise de negócio do que é aceitável ou não. Basicamente, o que eu estou querendo dizer aqui, que essa demora vai depender se o negócio aceita essa demora. Ou seja, eu tenho que verificar se eu posso ter essa demora na hora que eu vou fazer uma comunicação assíncrona. E eu vou trazer alguns casos para vocês que vão fazer mais sentido. Mas qual é a grande vantagem da comunicação assíncrona e eu vou trazer alguns casos para vocês que vão fazer mais sentido mas qual que é a grande vantagem da comunicação assíncrona de forma geral ela é mais barata porque porque a comunicação assíncrona a gente volta no caso do supermercado eu tenho os meus quatro caixas atendendo mas a partir de agora eu tenho oito pessoas aqui enfileirada tá? e essas pessoas enfileiradas aqui vão ficar aguardando até esse cara vir pra cá até esse cara vir para cá, até esse cara vir para cá, e esse cara fica esperando. Entendeu? Se esse caixa fechou, esse cara está aqui ainda. Quando o caixa voltou, ele vai para lá. Ou seja, eu não preciso ter tanto poder computacional para trabalhar com comunicação assíncrona. Se eu quisesse resolver problemas, todos os problemas com comunicação assíncrona, eu teria que garantir uma disponibilidade muito grande. Com comunicação assíncrona, eu perco uma coisa e ganho outra. O quê? Eu não necessariamente preciso ter o mesmo poder computacional, eu consigo processar as mesmas mensagens, as mesmas solicitações por outro lado, eu demoro mais pra responder né, e o que que acontece no final das contas existem casos que pra mim tá tudo bem se o usuário mandar uma solicitação e demorar um minuto para ele receber aquela resposta. São muitos casos, muitos e muitos casos que a gente consegue fazer isso. Tem o caso claro dos relatórios. Vamos imaginar que eu peço para gerar um relatório complexo. Se eu fizer isso de forma síncrona, o que vai acontecer? O cara vai travar o browser dele ali por 2, 3 minutos, 4, 5 minutos, pode até dar um connection timeout, ao ponto de, em tempo de execução, aquele relatório ter que ser gerado e retornado para o usuário. Agora, se eu tenho muitos usuários fazendo isso, olha a quantidade de poder computacional que eu tenho que ter simultâneo para conseguir fazer todos esses caras entregarem isso aí numa única chamada, numa única requisição. Então, quando você trabalha com um processo assíncrono, eu não preciso ter tanta estrutura computacional, mas ao mesmo tempo eu aumento o tempo de resposta. Porém, novamente, por isso que é uma decisão de negócio, muitas vezes qual é o problema de o cara demorar um minuto, dois minutos, cinco minutos, dez minutos? Depende muito do que você precisa, do qual é o objetivo da sua empresa. Às vezes o cara quer um relatório e, cara, o relatório está sendo gerado, você vai receber um e-mail ou clique aqui e a gente vai te avisar na hora que estiver pronto, e beleza isso aí fez com que eu economizasse 90% de infraestrutura que eu ia ter que disponibilizar e uma experiência do usuário completamente diferente e o grande problema aqui da nossa comunicação assíncrona é a parte de tolerância a falhas. Se eu peço fazer um relatório que chama um microserviço, que chama outro microserviço, que chama um microserviço, qualquer probleminha que der nesse meio do caminho, eu vou bater um erro lá de frente para o cara. Ou seja, eu tenho um efeito dominó muito forte aí nesses nossos casos e que novamente vai atrapalhar a experiência ali do usuário. O grande ponto aqui pra gente é sempre conseguir pensar que desde quando o mundo existe, existe algo chamado fila. Onde nem todo mundo pega tudo simultaneamente. As pessoas entram numa fila e quando chega a vez dela, ela é processada. Então, isso aí muda o jogo. Qual é o grande problema nos dias de hoje? É que muitos desenvolvedores, e não estou falando que são vocês, mas eu preciso contextualizar, trabalham com chamada síncrona 100% do tempo. Então ele faz esperar o relatório de um minuto, ou ele tem uma chance grande de o sistema, o outro está fora do ar e aquela informação ser perdida. Então existe várias situações que a comunicação síncrona é um mau negócio. E várias situações onde a comunicação assncrona é um mau negócio. E várias situações onde a comunicação assíncrona também é um mau negócio. Vou dar um exemplo aqui com vocês. Vou entrar no ticketmaster.com, comprei esses dias pré-venda Elevation Worship, a banda que eu custo pra caramba. Já fiz a pré-compra pra outubro no show que eu vou. Mas na hora que abriu essa pré-venda, um monte de gente estava ali querendo comprar. Você acha que uma comunicação assíncrona para o processo de compra, nesse caso, seria adequado? Eu compro, o outro cara compra, o outro cara compra, compra, compra, o mesmo assento, e daí, depois você fala, cara, olha, seu assento que você pensou que você comprou, já estava ocupado. Você fala assim, porra, estava ocupado, na hora que eu cliquei não estava ocupado, né? Ou seja, tem casos de uso que são inviáveis. Assento em avião, cara, né? Na hora que eu estou comprando, cara, aquela parada tem que acontecer na hora. O cara tem que estar pago, tem que estar garantido que a passagem esteja paga, que está tudo certo, porque eu tenho limites do tamanho de um avião, e não só limite, tem aquela cadeira com aquele preço que é já na janelinha que o cara escolheu. Então, esse tipo de situação não tem o que fazer, é situação síncrona, a não ser que você queira correr o risco de fazer overbooking e daí a gente acaba entrando numa outra seara o fato é que existem casos que não tem como não ser situações assíncronas, mas existem casos que situações assíncronas acontecem em situações que até a gente não pensa que existe por exemplo, Amazon. A Amazon, na hora de fazer a compra nos dias de hoje, ela faz o processamento assíncrono. Quando você clica, não aparece, pelo menos a Amazon dos Estados Unidos. Quando você clica na Amazon, não aparece. Compra aprovada. Cara, ele fala, recebemos o seu pedido. Entendeu? E daí ele vai processar. Se der algum problema, você vai receber uma notificação, você vai receber um e-mail, você vai receber, vá lá e mude as informações do seu pagamento. É isso que ela faz. Por quê? É tanta requisição, cara, é tanta requisição que eventualmente processar 100% disso em tempo real, pra eles, eles isso em tempo real, para eles, eles devem ter chegado em alguma conclusão que isso não deve ser viável. Ainda mais, sei lá, numa Black Friday. Como é que funciona todas essas solicitações? Imagina uma compra que eu quero fazer, que eu já tenho que sair com a nota fiscal ainda pronta, chamar o Cefaz, o Caramba 4. É inviável. Esses tipos de coisa tem que acontecer em background, tem que conseguir acontecer de forma assíncrona. Tá claro pra todo mundo, eu acho que é um conceito bem claro, eu acredito que vocês aí que são desenvolvedores sêniores já entendem, mas eu precisava balizar isso aqui com vocês. Bacana? Agora, protocolos de comunicação síncrona. Alguém consegue falar pra mim alguns protocolos, galera? Comunicação síncrona. Alguém consegue falar para mim alguns protocolos, galera? Comunicação síncrona, protocolos. Alguém consegue dar alguns spoilers aí para mim? Quais são protocolos que... HTTP, RPC... Socket, Wesley. Socket, o que mais? Vamos lá, eu vou pegar uma listinha básica aqui para a gente discutir em cima desses caras, tá? Não estou dizendo que eu estou colocando tudo que existe, porque eu não estou. Mas olha só. RPC, Remote Procedure Call Client Server chamando diretamente roda na maioria das vezes inclusive sobre o HTTP REST novamente, comunicação síncrona que é o que a gente está cansado de ouvir GraphQL, também roda, quando eu falo protocolos inclusive, eu estou falando de protocolos sobre protocolos por exemplo, o GraphQL, obviamente, ele roda em cima do HTTP, mas ele tem as suas especificidades. Da mesma forma como o REST, ele utiliza mais recursos das especificações do HTTP, exatamente para o HTTP não ter virado um RPC lá atrás, entendeu? GraphQL, GRPC, né? Eu queria falar um pouco desses caras aqui existem alguns caras que pra gente são claros e eu não vou ficar chovendo no molhado principalmente o cara do REST e o cara do RPC eu não sei quem aqui é da época do RPC que você fazia uma chamada RPC, XML RPC lembra? Ou seja, você tem, consegue executar remotamente uma operação num outro servidor. Baseado em XML, protocolo, SOAP, quem, quem, não sei quem é dessa época, adorava a mexer com isso, cara. Adorava mexer com isso. Tô sendo irônico, tá? Só pra vocês saberem. Pra não adorava mexer com isso tô sendo irônico, tá? só pra vocês saberem pra não pensarem que eu sou louco mas, conforme o tempo foi passando a gente começou a ter outras opções depois do REST GraphQL, quem aqui já trabalhou com GraphQL, galera? quem aqui já trabalhou com GraphQL? aí tem uma galera aí que já trabalhou cara, GraphQL é uma ideia fantástica, de uma ideia absurdamente fantástica, mas que simplesmente não vingou. Tá? Simplesmente não vingou. E quando eu falo não vingou, é não é massivamente utilizado da forma como um REST está sendo utilizado ou como um GRPC está sendo utilizado. Tá um gRPC está sendo utilizado. Mas é um cara que a gente pode encontrar. Quem aqui nunca ouviu falar em GraphQL? Ou entende como é que essa parada funciona? A grande pegada aqui do GraphQL é que eu digo o que eu quero de resposta. Eu falo que eu quero receber o nome, eu quero falar que eu recebo a descrição, eu quero receber a lista de produtos, mas a lista de produtos não tem o preço de compra. E ele vai me retornar um único documento. Com uma única chamada, eu consigo definir a resposta que eu quero receber. E isso aí é algo fantástico. Principalmente para a galera do front-end, cara. Lembro que na época que bombou o GraphQL, a galera do front-end se sentiu o rei. Por quê? Porque agora ele não depende do cara do back-end ficar fazendo um monte de endpoint pra ele. Porque ele consegue escolher o que ele pode e o que ele quer receber e como ele quer receber. Então, isso aí muda o jogo. É uma ideia fantástica da mesma forma que o GraphQL ele tem mutações, que é você conseguir escrever dados baseados nos formatos e no que, naquelas entidades que você quer alterar, tá? Galera, honestamente eu acho uma ideia fantástica tem muita utilização mas se você perguntar pra mim o porquê que isso não vingou, eu não sei tá? Eu não sei. Eu sei que teve muita fricção. O REST é algo muito consolidado, mas eu acredito que a adoção desse cara, no início teve muitos problemas de ficar fazendo chamadas em loop, conseguir trazer mais informações encadeadas, custo computacional, começaram a ter diversas discussões e no final das contas o GraphQL foi um cara que não vingou. Mas é importante vocês saberem que esse cara existe e que você pode encontrar diversos serviços hoje em dia que inclusive tem suporte para GraphQL. Agora, tem esse cara aqui GRPC esse é um dos caras que eu gosto de falar bastante porque ele é um protocolo que muda o jogo e que ele é muito pouco explorado por desenvolvedores tá? porque que eu estou dizendo isso? porque quando a gente está trabalhando aqui com o GRPC a gente está trabalhando aqui com o GRPC, a gente está falando num outro nível de velocidade de comunicação entre sistemas. Principalmente quando eu estou falando em comunicação entre microserviços. Eu tenho o microserviço A, que vai chamar o microserviço B. Imagina que eu estou dentro da minha rede, onde muitos microserviços estão se comunicando. Quando eu tô fazendo essa chamada aqui via REST, tá? Basicamente, o que eu tenho aqui no meio é um JSON. A maioria das vezes aqui eu tô rodando com HTTP 1.1. O meu conteúdo do JSON é um conteúdo grande, das vezes aqui eu estou rodando com HTTP 1.1 o meu conteúdo do JSON é um conteúdo grande o JSON é um conteúdo grande ele é human readable, ou seja a gente consegue ler e é muito bom a gente conseguir ler e ver como é que está o formato do nosso arquivo até mesmo para a gente entender como é que as coisas fazem o problema do JSON é que ele tem um problema de serialização barra des... des... barra des... Como é que eu escrevo deserialização? Vocês entenderam, né? Deserialização. Por quê? Cada vez que eu vou serializar esse JSON, ou seja, pegar um dado de algo e transformar isso em JSON, ou pegar algo que está em JSON e transformar, sei lá, na minha classe de objetos, eu tenho um uso intenso de CPU. Ponto, tá? E isso gasta máquina. Nossa, Wesley, mas isso deve ser contado na ponta do lápis? Cara, se você trabalhar em sistemas grandes, em grandes empresas, onde você precisa de baixa latência, sem dúvidas, isso aqui faz uma diferença gigante. Outra coisa, quando a gente está trabalhando aqui com REST de forma geral, a gente está limitado de forma geral aos verbos que o REST tem. Ou eu vou fazer um POST, ou eu vou fazer um PUT, ou vou fazer um DELETE, ou vou fazer um GET, etc. Ou seja, eu fico focado apenas em recursos. Então, isso aí é interessante. Eu fico focando apenas em recursos. Eu fico focando apenas em recursos. Eu não estou pensando em ações que podem mexer em diversos recursos e trazer informações de diversos recursos. O REST me engessa no formato que ele trabalha. E eu não estou dizendo que o formato que o REST trabalha é ruim. A única coisa que eu estou dizendo é que eu posso ter outros formatos de ações que eu quero executar que elas são mais expressivas entendeu? como faça a compra enviando não sei o que blá blá blá blá blá blá, gerando a nota fiscal estou dando um exemplo uma chamada, que é um pouco diferente de eu mandar um post para fazer a compra, depois um post para gerar a nota, um post para fazer isso, um post para fazer aquilo. Então, o que acontece aqui é o seguinte, o REST atende muitos casos, é óbvio. Mas se você quer baixa latência, se eu falasse para você que ao invés do JSON, eu vou trabalhar com um cara chamado Protocol Buffer. eu vou trabalhar com um cara chamado protobuffer, protocol buffer, tá? E esse cara aqui é um protocolo que de forma geral ele trabalha de forma binária. Ou seja, o tamanho do meu payload aqui, ele é irrisório, ponto. Porque ele é compactado, ele é um arquivo binário. Acabou. Estou mandando o binário. Outra coisa por padrão. Eu trabalho em cima do HTTP2, onde eu mando o dado em binário e eu ainda tenho todos os headers e todo o processo de comunicação também que eu consigo fazer isso de uma forma muito mais rápida. E a parte mais interessante no meio de tudo isso, eu consigo trabalhar com streams. O que significa? Eu consigo fazer esse micro serviço aqui, por exemplo, fazer o seguinte, eu envio uma resposta, uma pergunta, uma solicitação, e esse cara, ele pode responder essa minha solicitação aos pedaços. E conforme eu vou recebendo essas respostas desse cara, eu vou processando. Ou seja, eu não preciso esperar esse cara processar 100% da solicitação para eu ir pegando a resposta. Cara, isso muda o jogo. Fala a verdade quando a gente está falando em velocidade. Às vezes eu posso ir processando dados enquanto eu vou recebendo informações. Às vezes eu não preciso ter 100% da informação para eu conseguir receber e utilizar esses dados aqui comigo. Por outro lado, eu tenho um outro tipo de comunicação quando eu estou falando com o GRPC, que é o quê? Eu posso mandar a solicitação com um stream de dados aqui também. Eu vou mandando os dados e conforme eu vou recebendo esses dados, eu também vou processando esses dados. E daí, eu posso chegar e falar, ó, baseado conforme vocês foram mandando, eu fui processando em diversas threads aqui, e agora eu tenho a resposta final. Mas, eu também tenho a situação mais glamurosa, que o cara está mandando esses dados para mim e eu estou fazendo a minha resposta também no formato de stream. Tudo isso via HTTP. Agora, se eu falar para vocês o que é mais complexo de desenvolver, trabalhar com REST ou trabalhar com GRPC, o que vocês acham na minha opinião? Opinião de vocês, galera. O Ítalo falou REST. Tem gente falando REST, tem gente que tá fazendo o bendito Depende, gosto dos Dependes. Cara, eu digo o seguinte. Se eu tivesse aprendido GRPC antes do REST, talvez eu acharia REST mais difícil. Se eu aprendi REST antes do GRPC, a minha tendência é achar o GRPC mais difícil, tá? Então, o que que eu tô querendo dizer com isso, pessoal? O que eu tô querendo dizer é que, na minha opinião, e vocês não são obrigados a concordar, eu acho que fazer comunicação, tanto via REST quanto GRPC, dá exatamente o mesmo trabalho. Ponto. Na minha opinião, o trabalho é exatamente o mesmo. O ponto é que REST é padrão, tem uma adoção. E eu não acho, na realidade, que a gente acaba tendo dificuldades mais complexas. Tem muita gente que fala, o problema do gRPC é que é um arquivo binário e daí eu não consigo inspecionar. Mas, cara, você consegue inspecionar. Quando você recebe esse binário, automaticamente ele é deserializado e você consegue olhar esse cara do outro lado. Obviamente que você não consegue pegar o binário no meio do caminho e abrir ele, que é o que a gente faz com o JSON. Nesse ponto, eu concordo. Tá? Mas o fato é que, na prática, no dia a dia, minha opinião pessoal, a dificuldade de implementar gRPC e REST, na minha opinião, é exatamente a mesma. Mas temos casos de uso que são importantes. Quando eu recomendo vocês trabalharem aí com GRPC? Comunicação com micro serviços. Comunicação interna de sistemas se comunicando dentro da sua rede. Tá? GRPC falando com front-end, isso é uma coisa que não vingou. Tem o lance de web GRPC, o caramba, quatro. Cara, esqueçam pelo menos por anos, por um tempo sobre isso, tá? gRPC é serviço falando com serviço, tá? É basicamente o follow service chamando esse cara, esse cara chamando esse outro cara esses caras aqui falando via gRPC cara, o ganho de velocidade de latência curso de rede, o ganho de velocidade, de latência, custo de rede, quando você precisa de alta velocidade, cara, é simplesmente uma escolha de você escolher dois caras que, entre aspas, uma vez que você está familiarizado, vai dar o mesmo trabalho para você. E a maioria das pessoas não trabalham com gRPC porque elas não conhecem. E porque as pessoas que elas trabalham com gRPC porque elas não conhecem. E porque as pessoas que elas trabalham junto também não conhecem, então elas geram fricções de criar servidores gRPCs. Mas uma vez que você agora sabe que isso funciona, é rápido, eu convido e provoco vocês a desenvolverem qualquer coisa que faça comunicação entre dois sistemas com gRPC. Vocês vão sofrer um pouquinho no começo para entender a ideia do protobuf, mas a gente tem muitas vantagens. O protobuf tem um esquema onde você define o contrato. Acabou aquela história de mandar um inteiro entre parênteses, entre chaves, e ser uma string e quebrar o outro microserviço, entendeu? Então, esse aí é o grande ponto. O Rafael está falando aqui, mas aí a gente não cria acoplamento entre microserviços? Não, a gente não cria acoplamento nenhum. O acoplamento que você tem de gRPC entre um microserviço e outro é o mesmo acoplamento que você tem de trabalhar com REST em um microserviço e outro. A única diferença é a mudança do protocolo. Eu estava falando em português, agora eu estou falando em inglês. Eu estava falando em chinês, mas eu estou falando da mesma forma. Eu tenho o acoplamento da mesma forma, tá? Então, a ideia do GRPC, eu forma, tá? Então, a ideia do GRPC, eu acho uma pena grandes empresas, grandes desenvolvedores, não sentarem e começarem a utilizar mais exaustivamente isso, tá? O GRPC foi uma tecnologia desenvolvida pela Google e, por curiosidade, saibam que grande parte de toda a comunicação que roda entre os microserviços da Google hoje em dia acontece via gRPC tá? E daí novamente eu não sou o Google, então eu não preciso comunicação gRPC, não cara você pode estar trabalhando no Itaú, você pode estar trabalhando no Bradesco, no Newbank você pode estar trabalhando na Amazon você pode estar trabalhando no Mercado Livre você pode estar trabalhando em diversos tipos de empresa que recebem alta demanda, você vai ter um custo computacional muito mais baixo, uma comunicação e uma latência muito menor, você vai ter contratos muito mais expressivos que vai evitar as pontas ficarem quebrando e você tem mais opções de transferência de dados, porque você não fica apenas focado em request e response, você tem stream bidirecional, que se você é uma pessoa que gosta de trabalhar com multitrading, isso aí é uma mão na roda também que a gente acaba trabalhando, tá? Então, esse tipo de coisa, galera, é um ponto importante. Perguntaram aqui pra mim, por que você acha que não popularizou o GRPC? Cara, eu vou ser honesto, tá? Eu acho que GRPC popularizou mas eu acho muito difícil ter qualquer coisa mais popular que REST a adoção do REST é tão grande que pode parecer que a adoção do GRPC é ínfima, tá? mas na realidade não é se você começar a olhar grandes empresas que precisam de realmente velocidade, cara, GRPC é uma tecnologia madura, não é uma modinha, nada disso. Já é algo consolidado, entendeu? Então, façam os seus experimentos, galera. Novamente, de forma geral, você tem muito mais prós do que contras em utilizar GRPC para comunicação interna entre microserviços. Eu não tenho dúvidas disso. Você tem muito mais prós do que contras. O problema, a gente acaba caindo muito no problema cultural. As nossas documentações, a gente está acostumado a usar as documentações lá do OpenAPI e não sei o que. Ah, não sei o que, eu já estou fazendo dessa forma. A empresa utiliza. É muito, na minha opinião, uma mudança muito mais cultural e estrutural do que necessariamente do que necessariamente problemas de implementação, entendeu? Então, esse é um tipo importante. Então, por é um tipo importante. Então, por isso que eu estou falando aqui. Conversação entre microserviços. Um sistema chamando o outro. Cara, assim, as vantagens são enormes. Você tem mais vantagens, na minha opinião, do que desvantagem, a não ser o problema forte cultural que a empresa tem, e adoção, e aprender, a curva de aprendizagem, que na minha opinião é uma curva de aprendizagem bem baixa na realidade. Ok? Cara, esses são aqui alguns protocolos, assim, de forma síncrona, que ganham espaço e que eu acho que vale a pena todo mundo brincar de uma forma ou de outra, mas eu quero dar uma atenção especial ao GRPC. Tá? Então, isso aí é um ponto importante. O Lucas falou que trabalhou com o GRPC em uma empresa que usava o GRPC para comunicação do front-end com API. Cara, então, nesse caso, eu não recomendo. Tá? Na minha opinião, hoje, em relação à maturidade de RPC, a comunicação entre sistemas, entre back-ends, não em relação a back-end e front-end. Todos os testes, eu não sei como é que está agora, eu digo que faz um ano que eu não testo isso. Mas todas as experiências que eu tive passadas estavam longe de estar madura em relação a isso. Todas as experiências que eu tive passadas estavam longe de estar madura em relação a isso, tá? Agora, a gente tem outros pontos aqui que são importantes e a gente vai acabar falando em outras categorizações. Mas eu vou trabalhar aqui, nesse momento, trabalhar com comunicação assíncrona. Deixa eu apagar esses caras aqui pra não atrapalhar a gente a gente tem aqui as nossas comunicações assíncronas e não consigo remover esse cara aqui meu escaledro eu tenho as minhas comunicações assíncronas agora aqui comunicações assíncronas agora aqui. Comunicações assíncronas, a gente cai naquela ideia naturalmente de filas. Quando a gente está falando em comunicação assíncrona, a gente está falando em ter um intermediário. Ou seja, eu tenho um microserviço A que vai querer falar com um microserviço B através de um tópico ou de uma fila. Depois eu vou explicar pra vocês a diferença de tópicos, filas e como é que funciona essa ideia, tá? Tem o microserviço A com o microserviço B. E esses caras, eles vão falar um com os outros através de um message broker. Ou seja, esse cara ele fica o tempo todo recebendo mensagens e dados desse cara aqui. Se esse cara aqui estiver fora do ar, não tem problema, porque as mensagens elas estão aqui nessa fila. E uma vez que as mensagens estão aqui nessa fila, o que vai acontecer? A gente vai ter um delay maior para processar, porque esse cara está fora. Mas quando esse cara voltar para o ar, ele vai continuar de onde ele parou, processando as mensagens. Então, isso aí é um ponto importantíssimo para a gente conseguir cair naquela bendita história do supermercado, tá? O ponto é que quando a gente tá falando sobre comunicação assíncrona dessa forma, a gente tem alguns conceitos que são importantes a gente entender. Nós temos o conceito de algo que a gente chama de Pub-Sub, tá? O que que é o Pub? É o cara que vai publicar uma mensagem. O Publisher, tá? E a gente tem o cara que é o Sub, que é o Subscriber. O cara que tá interessado naquela mensagem. Quando a gente trabalha com Pub-Sub, a gente tem algo bem interessante, que é o que? Eu não preciso ter apenas um interessado para ler aquela mensagem. Eu posso ter diversos caras interessados. Então, o que acontece? Esses caras aqui, eles ficam o tempo inteiro fazendo e daí depende muito de polling, porque tem casos que fazem polling, tem casos que a mensagem é enviada pelo broker tá? Mas a verdade é que todos esses caras estão interessados pelas mensagens que esse cara aqui tá enviando, né? Então eu fiz uma compra, esse cara aqui tá interessado em processar o pagamento, esse em gerar nota fiscal, esse aqui de mandar para mudar o sistema de estoque. Todos esses caras estão interessados no meu processo de compra aqui. Então, os subscribers são pessoas que se inscrevem em determinado canal ou num tópico para ficar escutando o que vem ali de mensagem para mim. E quando vier essas mensagens, eu vou ler essa mensagem e vou processar essa mensagem. Fez sentido isso que eu estou falando aqui para vocês, galera? Fez sentido? Tranquilo isso aqui pra vocês o ponto aqui é que obviamente a gente tem diversas formas pra trabalhar eu vou dar um exemplo existe a plataforma de broker chamado Apache Kafka Apache Kafka ele é um exemplo bem clássico de PubSub onde você tem o publicador você tem algo que a gente chama de tópico, e a gente tem os consumidores, nesse caso aqui a gente chama eles de consumers, que eles vão fazer o quê? Vão ficar consumindo essas mensagens aqui, que foram publicadas por esse cara aqui. Basicamente, é isso que a gente tem. A gente tem um para N, tá? Ou seja, eu tenho um enviador de mensagens, um tópico, ou mais também, eu posso ter mais pessoas, mais sistemas enviando no mesmo tópico, tudo bem, mas eu posso ter N caras escutando esse tópico e utilizando essas mensagens conforme ele tem interesse, tá? Esse é o grande ponto. Perguntaram aqui, o que fazer quando o producer tenta enviar, mas o server está off? O server que você está falando aqui é o message broker? A gente pode conversar porque existem regras e mecanismos de resiliência, até mesmo pra partir do princípio que o seu Kafka, o seu RabbitMQ esteja fora. Normalmente, é muito raro um cara desse estar fora pelo fato dele rodar de forma distribuída. Então, ele trabalha no formato de clusters com vários nós, ele pode rodar em regiões diferentes, ele pode rodar em zonas de disponibilidade diferentes, então é muito raro esses caras caírem fora do ar. Mas tudo é possível, então existem regras, existem técnicas, patterns que você pode utilizar para você não perder esse tipo de mensagem. Esse aí é o grande ponto. Aí perguntaram, o ponto aí sempre gera a dúvida, e se o subscriber estiver off? Não tem problema nenhum desse cara estar off. Se esse cara está off, a mensagem está aqui ainda. Quando esse cara voltar para o ar, o que vai acontecer? Ele vai ler as mensagens de onde ele parou. Não tem problema nenhum do subscriber estar off. Porque essa mensagem fica gravada gravada aqui dentro, tá? Então, isso aí é um ponto super importante para a gente conseguir trabalhar, fechou? Maravilha? Então, essa é a ideia principal. Quais são pontos importantes para a gente entender de Pub Sub aqui nesse caso? O Apache Kafka trabalha com esse padrão. Mas tem algumas coisas aqui que vale a pena você saber de antemão. Imagina que aqui é um sistema de nota fiscal. E esse aqui é um sistema de estoque. Vamos imaginar que eu tô recebendo muitas mensagens aqui e esse meu sistema aqui, ele não tá dando vazão pra processar tantas mensagens aqui. E daí, o que que acontece? Eu preciso escalar e eu vou ter outro sistema de nota fiscal aqui. E aí, normalmente, a pergunta que sempre aparece aqui é esses caras, eles não vão receber mensagens duplicadas, já que os dois sistemas estão ouvindo o mesmo canal, tá? E a resposta, se a gente for falar dessa forma como a gente está vendo aqui, sim, esses caras vão ler as mesmas mensagens repetidas e duplicadas. Porém, você tem mecanismos de agrupar esses caras aqui. Eu consigo fazer um agrupamento desses caras, e esse cara aqui, eu consigo chamar ele de Consumer Group. E nesse caso aqui, eu posso falar que o nome dele é NFE. O que significa? Que todas as máquinas que eu criar para escalar esse serviço, na hora que eu escalar, eu vou falar, ele faz parte do grupo NFE. Isso significa que na hora que esses caras forem consumir essas mensagens, eles não vão mais consumir mensagens repetidas. Eles vão consumir mensagens diferentes. E Eles vão consumir mensagens diferentes. E por isso que a gente consegue escalar. Tá? Então, isso aí é uma outra situação que a gente consegue fazer ali com esses tipos de complexidade. Eu consigo fazer agrupamento. Tem gente que tá perguntando, ai, como é que fica trabalhando com hot partitions, etc. Cara, eu não vou entrar nesse assunto porque já começa a entrar em assuntos extremamente mais específicos e não é o nosso objetivo de hoje. Mas existem muitas e muitas técnicas para você trabalhar com hot partitions, principalmente trabalhando com keys específicas para garantir que determinada mensagem caia em partições diferentes. Eu não quero entrar e dar uma aula de Kafka hoje aqui pra vocês, porque eu quero falar de forma geral as tecnologias. Mas é importante vocês saberem que você consegue agrupar, sim, esses caras para que eles não leiam mensagens repetidas, tá? Então, isso aí é importante aqui pra gente trabalhar. Maravilha? Então, isso aí é importante aqui pra gente trabalhar. Maravilha? Então, isso aí é um fato e que dá pra resolver. Gente perguntando, e ordem dos eventos? Também consigo trabalhar com ordem e ordenar os eventos que eu vou receber em determinadas situações baseadas nas keys que eu vou trabalhar. O que você tem que entender é que existem sistemas que precisam processar algo em uma ordem e existem sistemas que não precisam processar mensagens em uma determinada ordem. Tudo tem vantagem e desvantagem. Normalmente, quando você quer garantir ordem, você começa a ter problemas de partition key, hot keys, hot partitions ali. Mas o ponto principal aqui, galera, é entendermos que esses meios de comunicação são caras que a gente usa no dia a dia e que dá para a gente trabalhar, tá? Quais caras que trabalham dessa forma? A Paxi Kafka. tá? quais caras que trabalham dessa forma? Apache Kafka e novamente, uma outra coisa que eu quero dar muita ciência e colocar muito pé no chão aqui pra vocês, tá? que é o seguinte um Apache Kafka ele é uma solução complexa de provisionar é uma solução complexa de manter e é uma solução complexa de manter e é uma solução cara tá então eu vejo muitos desenvolvedores empolgadíssimos com o Kafka porque ele tem muita coisa envolvida nele e que fala cara eu quero usar o Apache Kafka mas se você quiser o Apache Kafka pra que a maioria de tudo das coisas que você vai fazer vai ser simplesmente ler um tópico dessa forma e não usar todo um ecossistema que ele tem, dependendo da situação, talvez ele não seja a opção mais adequada pra você. Então tome muito cuidado na hora de escolher a tecnologia, tá? Porque existem tecnologias extremamente fortes, capazes, com latências extremamente parecidas ou eventualmente até melhores com a Apache Kafka, tá? O grande ponto aqui é o que você precisa. E é por isso que eu quero trazer esses assuntos, porque agora você sabe que a Apache Kafka é uma escolha, tá? Mas a gente tem outras escolhas, por exemplo, pra PubSub. Por exemplo, o Redis, a gente também consegue fazer PubSub com Redis. Alguém já tinha ouvido falar nisso? Ou alguém já usa o Redis pra PubSub, galera? usa o Redis para PubSub, galera? Eu consigo fazer PubSub com o Redis. Isso é muito louco. O Redis vai muito além de cache. Então, muitas vezes, você precisa fazer PubSub para que sistemas consigam ficar recebendo essas mensagens e fazer alguns processamentos e coisas desse tipo. Você já usa o Redis para cache. Cara, já está aprovisionado. Você pode usar o Redis para fazer PubSub. Então, isso aí é um ponto importante. Por outro lado, o Redis não é a melhor solução do mundo para você trabalhar com garantia de entrega e garantia de recebimento. Então, dependendo de como você for trabalhar com o Redis, você tem chance real de perder alguma mensagem. E é isso que começa a diferenciar a utilização de Redis, por exemplo, com Kafka e com outras soluções. Mas, se você, dependendo da situação que você está, no contexto que você está, você esteja talvez disposto a perder uma mensagem, que isso pode acontecer com o Kafka também se ele estiver mal configurado, porque o Kafka tem diversos mecanismos de garantia de entrega e de recebimento, você, naturalmente, tranquilamente, você pode trabalhar com o Redis, cara. É muito louco isso, dá para fazer muita coisa bacana com o Redis, então está aí mais uma opção para que vocês consigam entender como é que ele funciona. Fechou? Outro cara que também consigo trabalhar com PubSub, o Postgres. Quem aqui sabia que o Postgres também permite que a gente consiga fazer PubSub nele? Mais um cara que você pode levar em consideração. Eventualmente, você tem uma infraestrutura enxuta, tem o Postgres, você precisa trabalhar de uma forma talvez até um pouco mais simplificada com PubSub. Eventualmente, cara, por que eu não vou usar o Postgres, já que ele tem a possibilidade de trabalhar dessa forma? Entende? Galera, o que eu quero e o que eu sempre tento reafirmar aqui com vocês nesses nossos bate-papos, eu não estou aqui hoje para te ensinar Kafka, para te ensinar Redis, para te ensinar Postgres. Eu estou aqui para te mostrar que você tem opções. E que eu acredito que muitos de vocês não saibam que existem essas opções. A partir de agora, vocês não conseguem mais desver. Quando alguém for falar em PubSub para você, você já vai usar o Redis como um cara que pode ser um candidato de acordo com o problema que ele tem. Você entende? Aumentou o seu leque de opção. O meu objetivo dessa aula hoje é aumentar o leque de opção que você tem agora para trabalhar com comunicação entre sistemas. Vocês estão conseguindo entender o meu objetivo aqui, galera? Está ficando claro? Porque é uma aula teórica que eu estou dando aqui para vocês. É uma parada que tem muito menos prática até mesmo do que um system design, entendeu? Mas, quando você vê, você não consegue mais desver. A realidade é essa, tá? Então, é importante. Você sabe que tem, agora você sabe pesquisar, você sabe ir atrás. Já é uma possibilidade que você pode considerar. Porque o pior de tudo é você não saber que você não sabe. Porque daí você só ia ter o Kafka e o RabbitMQ na sua mente. E agora você tem o Redis, você tem o Postgres, por exemplo. Por outro lado, a gente tem outras ferramentas bem decentes que trabalham, e eu vou falar mais especificamente aqui, com filas e com protocolos, por exemplo, como a MQP, onde a gente trabalha num formato um pouco diferente desse que a gente está acostumado. A gente trabalha com formatos de hubs de comunicação. O que isso significa? Eu tenho o meu serviço A aqui, querendo se comunicar com o meu serviço B aqui. E aí, para isso, eu tenho uma fila. Legal? Então, eu tenho aqui a minha fila bonitinha. Porém, o que acontece? Eu posso ter aqui um cara entre a minha fila e o meu publicador chamado de exchange. Tá? Exchange. O que uma exchange faz, galera? Uma exchange, ela descobre pra gente pra qual fila uma mensagem vai ser enviada. E isso aí muda o jogo na hora que você vai organizar a forma como seus sistemas vão se comunicar. Vou dar um exemplo aqui para vocês. Vamos imaginar que eu mando uma mensagem pra essa minha exchange agora aqui. Tá? Essa mensagem pra minha exchange eu vou falar aqui pra ela que eu vou mandar uma key aqui pra ela tá? Igual a x. Vou colocar x por enquanto aqui. A minha exchange aqui pode ter diversas filas plugadas nela. Eu tenho diversas filas plugadas nessa minha exchange. Basicamente dessa forma. Quando eu plugo essa minha fila nessa exchange, eu posso falar aqui que essa minha aqui é X. E eu posso falar que essa minha aqui é x e eu posso falar que essa minha aqui também é x o que que isso significa? que a mensagem que eu estou enviando deixa eu ver se eu tenho um desenho de mensagem aqui tem um desenho de mensagem? cara, que chato, eu lembrava que eu tinha um eu vou criar uma mensagenzinha aqui eu vou pegar uma mensagenzinha aqui. Eu vou pegar uma mensagenzinha aqui. Essa mensagem que eu ia enviando, eu faço o seguinte, eu mando uma mensagem e eu falo que nessa mensagem aqui dela é X. Deixa eu tirar aqui daqui. Aqui vai na minha mensagem. Quando ela cair aqui na minha Exchange, ela vai falar o seguinte, olha meu amigo, eu estou aqui com uma mensagem, e a minha aqui é X. Para onde eu vou? Daí ele vai falar, você vai para essa fila, e você também vai para essa fila. E aí eu posso ter o microserviço B lendo essa fila aqui e eu posso ter o microserviço C lendo essa fila aqui e essa fila simplesmente vai receber essas mensagens duplicadas. Ou seja, ele é um roteador de mensagens aqui para a gente. E eu consigo colocar regras nele. E é muito interessante que conforme eu coloco regras, eu consigo ter um manuseio muito mais otimizado de quem vai ler cada dado de uma fila. Porque eu posso falar aqui que toda mensagem x.asterisco vai cair nessa fila. E toda mensagem que for y.asterisco vai cair nessa fila. O que significa? Vamos imaginar que eu estou mandando uma mensagem e eu vou mandar um log e eu vou falar x.log aqui nessa minha mensagem, nessa minha aqui. O que vai acontecer nesse meu caso? Eu vou, essa mensagem vai cair aqui e ela vai mandar para cá. Entende? Então eu consigo brincar, inclusive com wildcards, onde eu consigo isso ponto asterisco, ponto asterisco vai para essas filas, esse vai para essa fila, esse vai para essa fila. E a minha exchange, ela consegue gerenciar tudo isso e eu tenho várias filas conseguindo fazer esse consumo. Então, a ideia padrão de soluções que trabalham dessa forma, elas usam um paradigma diferente, porque não é necessariamente aquele pub-sub padrão, onde o A manda uma mensagem que cai para o B. O A manda uma mensagem para uma para o B. O A manda uma mensagem para o MyExchange, essa mensagem tem regras e essas regras baseadas nessa mensagem, eu escolho para quais filas que eu vou mandar esse cara aqui para a gente. É basicamente isso que começa a acontecer. Por padrão, e aqui os casos mais claros aqui, uma ferramenta que mais é comum que todo mundo ouve falar e etc, é o RabbitMQ que usa isso extensivamente, tá? Então você tá falando de RabbitMQ, é um cara que trabalha nesse padrão aqui com com essas, com as exchanges aqui pra gente, tá? Existem alguns pontos que são importantes em levar em consideração, tá? com as exchanges aqui para a gente. Existem alguns pontos que são importantes em levar em consideração. Existem muitas configurações que você pode fazer no RabbitMQ. Por padrão, de forma geral, toda vez que o usuário C ler essa mensagem e confirmar essa leitura, essa mensagem é apagada da fila. E essa mensagem e confirmar essa leitura, essa mensagem é apagada da fila. E essa mensagem vai embora. Ou seja, eu não guardo essas mensagens pra sempre na minha fila. Uma vez que ela é consumida, ela vai embora. A Pachicafka, por exemplo, ele mantém as mensagens mesmo que eu leia mais de uma vez. Ou seja, ele permite a releitura e o reprocessamento da mesma mensagem. Obviamente que no Apache Kafka você configura também um TTL para as mensagens para você não criar um banco de dados infinito, tá? Mas de forma geral, no RabbitMQ, você trabalha com mensagens que são descartadas todas as vezes que elas são lidas. Então, isso aí é interessante a gente conseguir entender. Teve alguém, o Daniel, postou um simulador do RabbitMQ. Eu uso muito esse simulador na hora que eu vou dar aulas de RabbitMQ, porque essa dinâmica aqui fica mais clara para vocês entenderem. Mas o fato aqui é que o RabbitMQ é uma ferramenta monstruosa. Ele consegue ter ali o processamento e fazer processamento de uma forma extremamente forte, ele consegue trabalhar também de forma distribuída, tá? E não tem essa que o Kafka é o melhor que o RabbitMQ ou que o Kafka é mais rápido, etc. e tudo mais. Não necessariamente, tá? Dependendo da situação, você consegue ter a mesma latência que o Kafka tem com o RabbitMQ. E, muitas vezes, ele consegue receber a mesma paulada de mensagens que o Apache Kafka. Porém, a arquitetura do Apache Kafka em si é uma arquitetura bem diferente de como o RabbitMQ funciona, porque ele trabalha com as partições de forma distribuída. Então, você tem, de forma geral, uma resiliência muito maior, você tem uma sincronização de mensagens muito maior, e o Kafka, de forma geral, ele se vê como uma plataforma de stream de dados, e não uma plataforma de mensageria. Obviamente que um stream de dados, e não uma plataforma de mensageria. Obviamente que um stream de dados pode ser uma mensagem, entenda? Mas stream de dados, normalmente, a gente está falando de fluxo contínuo de informações. O que eu estou querendo dizer com isso? Por exemplo, o Kafka, ele permite que conforme os dados vão seguindo, eu tenho uma parada chamada KSQL DB, que ele consegue fazer cálculos em tempo real como se fosse um SQL agregando informação desses streams de dados que estão chegando. Ou eu tenho o Kafka Streams, que faz isso ali de uma forma mais programática. O Kafka tem, por exemplo, um cara chamado de Kafka Connect. Esse Kafka Connect ele é plugado do seu broker do Kafka e ele permite que os dados que a gente receba aqui pelo amor de Deus, eu não estou plugando o Kafka Connect no Exchange. Esse Kafka Connect ele permite que a gente grude no Kafka, tá? E daí o que acontece? O Kafka Connect pega essas mensagens e automaticamente ela consegue enfiar isso aqui no MySQL, ela consegue botar isso num Mongo, num Elasticsearch, e em diversos outros tipos de ferramenta. Então, imagina que você quer fazer uma integração entre sistemas. Imagina que você tem um sistema, que você tem uma listagem de compras. Ok? Novos produtos estão sendo comprados o tempo todo. O quão trabalhoso seria para você ler os dados numa fila, desenvolver um worker que vai pegar esses dados e inserir no banco de dados que você precisa. Vocês concordam comigo que isso dá trabalho, galera? Dá trabalho. Eventualmente, não pode ser a coisa mais complexa do mundo. Eu pego um dado do Kafka, trato essa informação, e insiro no banco de dados. Concordam comigo? Dá um trabalhinho, mas ainda assim eu estou desenvolvendo um software, eu estou tendo que fazer o deploy, tenho uma esteira de CICD, tem um trilhão de coisas que eu tenho que fazer para esse worker fazer isso. O Kafka Connect, ele permite fazer isso de uma forma automática. Eu simplesmente plugo o resultado do Kafka no meu banco de dados e automaticamente ele está inserindo essas informações para mim e eu não precisei desenvolver absolutamente nada. Imagina fazer integração e sincronização de sistemas com isso. Porque concorda e a gente acaba indo para um outro nível? Imagina eu ter um sistema que eu recebo dados e esses dados são inseridos em diversos sistemas simultaneamente em diversos bancos de dados. A gente começa a entrar em um outro nível de ecossistema. Então, quando a gente está falando de Kafka, a gente está falando do Kafka, do Kafka Connect, o Kafka tem o proxy, que você faz chamada REST, e ele cai num tópico. Então, o Kafka tem uma gama de recursos em volta dele que faz o Kafka ser o Kafka. Entendeu? Então, se você quer só trafegar mensagens para uma pessoa ler e outra processar, e você só precisa disso, dependendo da situação, você não precisa do Kafka. E você só precisa disso, dependendo da situação, você não precisa do Kafka. Agora, se você quer tirar proveito de todo um ecossistema que ele tem em volta, sem dúvidas, o Kafka é uma baita ferramenta aí para vocês. Fez sentido para vocês, galera? Eu vou parar para tirar algumas dúvidas aí, para eu não ficar só no monólogo aqui. Dúvidas? Temos algumas pessoas com mãos levantadas. Perguntem, galera. Se eu souber responder, eu respondo. Wesley, qual dessas ferramentas de mensageria você acha que é melhor para o cenário onde a gente precisa manter uma ordem de mensagens? Ou seja, eu recebi uma mensagem, dez mensagens, numa determinada ordem de mensagens, ou seja, eu recebi uma mensagem, dez mensagens, numa determinada ordem, e eu preciso que elas saiam da fila nessa mesma ordem de mensagens. Eu ouvi dizer que o Apache Pulse, não sei se você conhece, é bom pra isso. Não sei se o Rabbit também é bom pra isso ou não. Cara, em todos você consegue criar estratégias que você consegue garantir ordem de mensagem. Principalmente, por exemplo, RabbitMQ. RabbitMQ é first in, first out. Mensagem entrou, você vai consumir ela na ordem. O problema ali é quando você tem vários consumidores consumindo a mesma fila. E aí que você pode ter a complicação de a gente ter esse problema de ordem. Não sei se você entendeu o que eu estou querendo dizer. Eu vou dar um exemplo só para vocês entenderem como que o Apache Kafka funciona aqui para vocês. Vou dar um exemplo do Kafka para vocês entenderem o problema da ordem de como que as coisas acontecem. O lance é o seguinte. Imagina que eu tenho um broker aqui do Kafka e esse broker, ele é formado de partições, tá? É basicamente isso aqui, tem partição 1, 2 e 3, aqui pra mim. Partição A, partição B, partição C. Quando eu envio uma mensagem pro Apache Kafka, o que vai acontecer? Essa mensagem, naturalmente, o Kafka vai usar um algoritmo dele e, eventualmente, ele vai mandar essa mensagem para a partição A, ou para a partição B, ou para a partição C. Por que ele tem essas partições? Tem alguns motivos e depois eu explico para vocês. Mas um motivo aqui vai ser bem claro. O que acontece é o seguinte. Quando eu tenho os meus consumidores, que vão ficar lendo as minhas mensagens no Kafka, vamos imaginar que eu estou em um consumer group. Lembra que eu tenho aquele grupo. Vamos fingir que a gente está todo mundo dentro do grupo B aqui. Então, eu tenho várias máquinas aqui do grupo B escalando. Se eu, dentro desse grupo que eu estou aqui, deixa eu fazer o agrupamento desse cara. Estou dentro desse grupo e eu tenho três máquinas aqui. O que vai acontecer? Essa máquina vai começar a ler essa partição. Essa máquina vai ler essa partição. Essa máquina vai ler essa partição. Se eu tiver um outro B aqui, adivinha o que acontece, fala aí pra mim Leonardo o que você acha que acontece, cara? eu acho que ela volta no A não volta, ela fica parada hum, entendi é somente um consumidor por partição por isso que você, na hora que você cria um tópico no Kafka você vai definir quantas partições você quer se você cria muita partição você vai definir quantas partições você quer. Se você cria muita partição, você vai ter que ficar fazendo caras lendo várias partições. Se você cria pouca partição, você não consegue escalar. Então, ao longo do tempo, você vai encontrando um número ótimo de partições que você cria para você conseguir escalar e fazer essas leituras em paralelo. Qual é o problema na ordem das mensagens? Eu acredito que o problema começa a ficar claro aqui para mim. Vamos imaginar que a mensagem 1... Vamos imaginar que a gente tem aquela nossa mensagem aqui. A mensagem 1 foi para cá. A mensagem 2 foi para cá. A mensagem 3 foi para cá. A mensagem 3 foi para cá. E a mensagem 4 foi para cá. Beleza? Esse cara começa a consumir. Mas esse cara aqui, ele começa a ficar meio lento. O que vai acontecer? Esse cara vai processar a mensagem 2. Esse cara vai processar a mensagem 2, esse cara vai processar a mensagem 4, e depois esse cara vai processar a 1 e a 3. O que vai acontecer? Eu estou processando fora da ordem. Concorda comigo, Leonardo? Opa, concordo, sim. Você leu primeiro 2, quatro e depois um e três entendeu? ferrou se eu preciso de ordem aqui, isso aqui não vai resolver a minha vida porém, o que que eu posso fazer? na hora que eu coloco essa mensagem aqui eu falo que essa mensagem ela tem uma aqui tá? vou falar que eu falo que essa mensagem tem uma Q. Vou falar que essa mensagem tem uma Q, que é chamada... Uma Q que é A, vamos dizer assim. E essa mensagem 3, eu também falo que ela tem uma Q, que ela é A também. A mensagem 2, eu falo que ela tem uma Q, que ela é A também. A mensagem 2, eu falo que ela tem uma aqui, que ela é A também. E a mensagem 4 aqui, eu falo que ela tem uma aqui, que é B. O que que isso significa? Todas as vezes que eu enviar uma mensagem, e essa mensagem tiver uma aqui, eu vou mandar a mensagem 1, ela vai cair aqui. Como essa aqui é a A, esse A aqui não tem nada a ver com o A daqui, tá, galera? Só para vocês saberem. Eu vou até mudar partição 1, partição 2, partição 3, só para não misturar, tá? Quando essa mensagem está com a A aqui, a próxima mensagem que chegar e que estiver com a mesma aqui, vai cair na mesma partição. E o que que acontece? O B vai processar. E esse B vai processar na ordem que a mensagem chega. Então ele vai processar a 1, a 2 e a 3. Aí eu consigo garantir a ordem. Entendeu? Mas e se ele estiver lento, que nem você falou, e o de baixo, lê lá, por exemplo, que está no 3? O 3 aqui, ele está com uma outra aqui. Então a ordem para mim aqui eu não estou importando. Estou dizendo aqui que mensagens que eu estou na ordem são casqueadas. Ah, entendi. Você entendeu o que eu estou querendo dizer? Se eu quiser uma ordem, eu dou uma chave pra ela. Exatamente. Se eu não der uma chave, vai entrar randomicamente. Se eu der uma chave, se entrar uma mensagem 5 agora aqui, e a chave dela for B, ela vai cair na partição 3. Obrigatoriamente, aqui pra mim. Em momento algum, o Kafka coloca uma chave A em partições diferentes, né? Jamais não. Ele não vai trabalhar. Mas a vida é uma caixinha de surpresas. Quem lembra dessa, né? Joseph Glimmer. Joseph Glimmer. Qual que é o problema de a gente ter isso? A gente, dependendo do tipo de mensagens que a gente tem aqui, a gente acaba entrando em algo chamado de Hot Partitions. O que isso significa? Significa que se eu tenho muitas mensagens que precisam ser necessariamente lidas exatamente naquela ordem, somente esse meu B vai conseguir processar. E eu não consigo escalar isso. Você entendeu o meu problema? Se essa minha partição ficar muito quente, eu começo a ter um problema aqui. E aí, começam, entre aspas, as gambiarras. Eu não vou falar gambiarra, mas é uma gambiarra. Você começa a criar keys, meio que compostas, que você garante a leitura de uma, depois você lê, tipo, A1, A2, tipo, QA, depois eu tenho A1, A2, A3. Aí, esse cara lê todos os A numa ordem, todos no B, mas na hora de processar, eles têm uma regra interna onde eles conseguem dar um merge na ordem que esse cara vai processar, por exemplo, entendeu? Existem diversos... Quem aqui trabalha com Redis? Eu trabalho. Trabalhou já com ele de forma distribuída? Não, ainda não. Charts, né? Ainda não. Exatamente. O Redis você tem exatamente o mesmo problema. Quando você escolhe uma determinada key ali pro cara, esse cara vai ficar num shard. E aí se você começar a encher daquela key naquele cara, você vai ter um shard um hotkey novamente ali. Você vai ter um shard muito grande e com outros shards menores. E daí você começa a fazer keys com prefixos, keys de falar, olha, key underline 1 vai para o shard 1, key underline 2 vai para o shard 2. Quando eu pego, eu dou um union dessa parada e pego a lista que veio de todos os shards e consolido, entendeu? Então você começa a trabalhar com essas artimanhas para tentar resolver esses tipos de problema. Fez sentido isso que eu estou falando para vocês, galera? Ah, fez sim, com certeza. E o Rabbit é mais ou menos da mesma forma? O Rabbit não. O Rabbit acaba não tendo muito esse problema, porque eu posso trabalhar com exchanges e falar, eu vou criar 10 filas dessa, as mensagens, ou eu vou criar uma única fila, entendeu? E essa fila tem uma aqui, esse cara vai ficar processando. Acaba caindo exatamente na mesma situação do Kafka, entendeu? Sim. Porque eu também tenho uma Q aqui. Sacou? Agora, se eu quero processar agora, tem um ponto interessante aqui, é que eu posso plugar mais um cara C na mesma fila do Rabbit. Tá? E aí esses caras vão processar em paralelo aí eu tenho o problema da ordem de novo tá? se o C1 demorar mais pra processar o C2 vai processar e etc tá? então esse problema de processar na ordem é sempre um problema tem muitas estratégias que você pode trabalhar dentro da sua aplicação tem gente que trabalha com buffers de mensagens, depois eles consolidam depois. Cara, tem um trilhão de opções e a gente poderia fazer uma live só disso e ainda eu teria que chamar outros caras que trabalham o dia inteiro fazendo essas gambiarras pra me ajudar, porque eu não tenho comparado a essas pessoas que trabalham especificamente com cáfica, com esse tipo de problema de ordem, eu não chego nem perto do nível de experiência que esses caras têm. Entendeu? Então, não tenho problema nenhum, inclusive, de falar isso, entendeu? Mas, é importante a gente entender as limitações e essas coisas que acontecem, mas eu acho que ficou claro aqui pra vocês, né? Ficou sim, cara, valeu. Ficou claro e um outro ponto importante que o Kafka tem aqui pra gente, que ele acaba trazendo é que esses caras aqui e essas partições, isso aqui fica num broker que vai ser basicamente um node aqui e aí o que que acontece? essas partições, isso aqui fica num broker. Que vai ser basicamente um node aqui. E aí o que acontece? Eu vou ter vários brokers desse. Tá? Meio que dessa forma. Onde aqui eu posso ter a partição 1 Partição 1 do tópico 1. Eu posso ter aqui a partição 2 do tópico 2. Eu posso ter aqui a partição 2 do tópico 1. Aí, aqui, eu posso ter a partição 2 do tópico 1, mas aqui eu tenho a partição 3 do tópico 1. Sacou o que eu estou dizendo? Por que ele varia essas coisas aqui? Porque eu consigo escolher quantas cópias eu tenho de uma partição entre os meus brokers. E por que isso é importante? Porque se esse broker cai do ar, eu automaticamente o outro assume para que os caras comecem a ler daquela partição que ela tem uma cópia. E isso é a grande beleza do sistema distribuído do Kafka. Entendeu? Porque eu falo algo que a gente chama de replication factor e eu falo, olha, eu tenho 10 partições, meu replication factor é de 2 ou de 3. Significa que dessas 3 partições, elas vão estar dessas 10 partições ela vai ter 3 cópias de cada partição nos brokers que eu tenho. Então, se cai um broker, eu mantenho a disponibilidade. Se cai outro broker, eu ainda mantenho a disponibilidade. É basicamente assim que o Kafka trabalha. E quando ele volta, ele se atualiza sozinho? É, ele se atualiza sozinho. Normalmente, o cara que virou o líder, ele se mantém como líder, mas ele tem todo o esquema de rebalanceamento e tudo mais, tá? Mas de forma geral, o Kafka ele trabalha dessa forma. Ele tem cópia das partições. Então as partições ajudam a eu conseguir fazer essas leituras específicas por consumidor e elas me ajudam a ter cópias, onde eu garanto muito mais disponibilidade. Porque você não consegue fazer backup de forma geral de um broker. Não tem sentido, porque é dado em tempo real, entendeu? Então, o seu backup é o backup online que está rodando. Na realidade, é isso que está acontecendo, entendeu? E por isso que você tem esses montes de cópias dessas partições. E daí você fala, eu quero ter três cópias. Cara, você vai duplicar a quantidade de dados em três. Eu quero ter três cópias, cara, você vai duplicar a quantidade de dados em três. Eu quero ter cinco cópias, eu vou duplicar, mas daí eu preciso ter uma quantidade grande de brokers também, porque se cai um broker, vai cair um monte de cópia também, não faz sentido. Então, é somente pra vocês terem mais ou menos essa ideia. Fez sentido, galera? Boa. O Wesley... Esse broker é tipo um hide né Não O broker onde eu digo que é um broker Ele é um node do Kafka Tá Esse cara aqui é um Kafka broker Ou seja, aqui ele tem o software do Kafka Onde ele recebe Essas informações O broker Ele possui tópicos, os tópicos possuem partições e as partições têm segmentos que no final das contas a gente tem um log. O log basicamente é... O Kafka, por que ele é muito rápido? Porque o Kafka, ele é um banco de dados. Um dia eu fiz um post desse no Instagram, galera, e eu tomei xingo pra tudo quanto é lado, tá? Tomei xingo pra tudo quanto é lado, gente falando que eu não sabia o que eu tava falando, tá? Mas na realidade, o Kafka, ele é um banco de dados. falando, tá? Mas na realidade o Kafka, ele é um banco de dados. A diferença é que ele trabalha um formato de log. Entra uma mensagem, caiu aqui, entra outra mensagem, caiu aqui, aqui, aqui, e as mensagens vão entrando, e essa mensagem pode ser de qualquer tipo de dados, e isso aí é imutável. Simples assim. Por que ele é rápido? Porque ele não passa pelos layers de um banco de dados comum. Por exemplo, se eu estou em um banco de dados relacional, eu vou ter que ter a parte binária, que é a base que todo banco de dados relacional tem. Acredito que vocês manjam disso, que é mais ou menos o que o Kafka tem. Aí eu tenho o motor, aí eu tenho a sincronização, aí eu tenho os índices, eu tenho um monte de coisa. Por isso que o meu banco de dados é lento, de forma geral. Porque ele tem toda essa parada. O Kafka, por que ele é rápido? Porque é só leitura de dados, um atrás do outro, sequencial e mutável. Tem como ser mais rápido que isso? Sacou? Então, quando você trabalha dessa forma, e sem pensar em nada, a latência do Kafka, muitas vezes, para conseguir pegar as informações desse banco, ela consegue ser, inclusive, similar, muitas vezes, a conseguir pegar as informações desse banco, ela consegue ser, inclusive, similar, muitas vezes, à chamada de um banco de dados em memória. Tem estudos que o cara que fez o Kafka, tem um paper famoso dele que ele era o fundador da Confluent e ele trabalhava no LinkedIn quando criou o Kafka. E tem muitos estudos que você mostra que essa latência, ela acaba sendo muito parecida com uma chamada no Redis, dependendo da situação. Essa chamada, tá? Essa leitura desse dado. Então, sim, o banco, o Kafka, ele funciona como um banco de dados. Por exemplo, quem aqui já trabalhou com Event Sourcing? Hein, galera? Alguém já trabalhou aqui com CQRS depois normalmente tem Event Sourcing o Event Sourcing o que ele faz? você pega todos os eventos que acontecem dentro do seu sistema e anota esses eventos e guarda esses eventos se um dia você precisar reprocessar todos os eventos do sistema pra ele voltar no estado que ele tava naquele momento você consegue isso você é capaz de fazer utilizando o Kafka no estado que ele estava naquele momento, você consegue. Isso, você é capaz de fazer utilizando o Kafka. Eu posso criar e guardar todos os meus eventos que acontecem na minha aplicação, jogam a mensagem do Kafka. Se um dia eu quiser partir do zero do meu sistema, o que eu faço? Eu peço o meu sistema a ler evento por evento, processar, processar, processar processar e em tese meu sistema deve ficar como ele é hoje entendeu? Ou seja, o Kafka é uma fonte de dados o Kafka, ele é um banco de dados se você pegar qualquer pessoa que trabalhe diariamente com o Kafka e você chegar Kafka é um banco de dados? ele vai falar que sim, eu posso usar Kafka como um banco de dados, ele vai falar que sim. Eu posso usar Kafka como um banco de dados. Não da forma como a gente está acostumado a utilizar um banco de dados, mas ele sim é um banco de dados. Ok? Maravilha, galera. Mas o nosso bate-papo hoje, ele está longe de ficar, inclusive... Caraca, esse negócio de annotate aqui fica me enchendo o saco. De apenas Kafka porque a gente está ainda em comunicação assíncrona ok? deixa eu jogar essa parada aqui para o lado só para se eu precisar dar algum exemplo, a gente tem aqui mas fora isso a gente tem outras formas de comunicação e que eu separei a categorização dela um pouquinho diferente, que é tempo real. É comunicação síncrona, mas ela entra num outro patamar, que é no caso WebSockets. O que o WebSockets faz? Quem aqui já trabalhou com WebSockets? Muita gente já trabalhou com WebSockets? Muita gente já trabalhou com WebSockets. O grande ponto é que poucas pessoas, e não estou falando que é o caso de vocês, sabem como um WebSocket funciona. O WebSocket, no final das contas, ele acontece via uma chamada HTTP. Mas, na chamada HTTP, é feita a solicitação de um upgrade do protocolo de comunicação. Se vocês fizerem um MBA, vocês vão ver isso aí, inclusive. Mas é feito um upgrade na comunicação. Então você manda a solicitação falando que você quer se comunicar com o WebSockets, solicitando o upgrade da sua comunicação HTTP, e esse upgrade vai, no final das contas, manter um canal TCP aberto. E aí, o que acontece? Quando você tem um canal TCP aberto, E aí, o que acontece? Quando você tem um canal TCP aberto, eu consegui manter um canal de comunicação bidirecional entre cliente e servidor. E aí permite que eu, como cliente, posso enviar mensagens e receber mensagens também de um servidor. E aí a gente está falando, por exemplo, em chats, sistemas que tem que ficar onde eu mando mensagens e recebo mensagens em tempo real. WebSockets é uma mão na roda, mas o importante que vocês consigam entender é que o WebSocket ele acaba virando uma extensão do HTTP, porque você inicia a comunicação HTTP e depois ela é feita um upgrade no meio do processo. Tá? Isso aí é um ponto importante pra vocês entenderem. Agora, uma outra forma de trabalhar de forma síncrona é através de SSE, Server Sent Events. E eu fico surpreso como muitas pessoas não conhecem Server Sent Events. E acabam, muitas vezes, utilizando WebSockets pra tudo. Muitas pessoas não conhecem server-sent events. E acabam, muitas vezes, utilizando WebSockets para tudo. Tá? O que o server-sent events faz? Ele consegue estabelecer uma conexão persistente entre cliente e servidor. Porém, essa comunicação ela não é bidirecional ela é unidirecional pro servidor tá? então, eu vou dar um exemplo pra vocês vamos imaginar que eu preciso ficar recebendo informações em tempo real das compras que estão acontecendo no meu site tá? muitas pessoas por padrão fariam uma conexão com o WebSocket pra conseguir ficar recebendo essas compras, falem a verdade sejam honestos pra mim fariam com o WebSocket, não faria? grande parte da galera faria com o WebSocket mas você precisa falar com o servidor uma vez que você está recebendo essas informações, você não precisa. Então, você consegue trabalhar com uma parada chamada SSE, que é Server Sente Events, onde você apenas fica recebendo as notificações e você não precisa trabalhar ali com WebSockets, que muitas vezes é bem custoso. Então, vale a pena vocês olharem com muito carinho o Server Center Events. Uma coisa que é interessante do SSE é que é muito fácil trabalhar com SSE, galera. É muito fácil trabalhar com SSE e não tem muito segredo. É uma coisa muito direta e, obviamente, hoje frameworks devem ter implementações simples de utilizar SSE, tá? Então, SSE é uma forma muito boa pra você falar em tempo real, recebendo informações de forma unilateral pra que você não precise ficar trabalhando com WebSockets para tudo. Ok? Wesley. Oi. Esse caso, você está falando tempo real síncrono, o WebSockets, server-sentient event, mas isso é mais para no caso de um front-end, porque se você estiver no back-end... Sim, sim, sim, sim. Sim, sim, sim. Front-end. Principalmente front-end, né? Porque se você estiver no back-end... Sim, sim, sim, sim. Sim, sim, sim. Front-end. Principalmente front-end. Não que eu não consiga estabelecer uma conexão WebSockets entre dois back-ends. Eu acredito que sim. Você consegue, obviamente, estabelecer uma conexão SSA entre back-ends. Você consegue, com certeza. Mas eu acho que o principal ponto de uso que você vê no dia-a-dia, normalmente, 90% das vezes, 95% das vezes, você vai ver isso no front-end. Mas, nada impede de você ter back-end client-server que consiga trabalhar com WebSockets e trabalhar com server-centered events. No final das contas, é uma conexão estabelecida via HTML. Protocolos MCP utilizam SSE, né? Tem implementação em SSE, mas não está sendo uma boa adoção. A maioria das pessoas com MCP está... Grande, quase todos. Eu não conheço hoje em dia quase nenhum a implementação de MCP utilizando SSE. Está tudo usando o SDIO, de forma geral. Mas sim, ele tem um meio de transporte no MCP, a gente vai falar sobre MCP hoje, com a parte de SSE. Então, MCP também implementa SSE. Mantém uma conexão persistente com o client e server. Aplicações do tipo Google Docs, da família, que é uma colaborativa, né? Cara, isso é WebSocket. É WebSocket? Com certeza, porque você troca a mensagem com o server e recebe a mensagem em tempo real. É bidirecional a conexão. Sim, nesse caso. E o caso do use case do SSE, qual seria uma notificação, tipo, o sistema de notificação de rede social, por exemplo, que você só recebe? Cara, imagina, você tem um dashboard com tudo acontecendo, seus pagamentos chegando, suas ordens de serviço, como é que tá suas ações como é que recebi uma notificação de que o meu pagamento foi aprovado, cara, tem basicamente tudo que você precisa ficar recebendo mensagem, você consegue trabalhar com isso, entendeu? Inclusive, pessoal, deixa eu até olhar aqui uma coisa fazendo jabá e não fazendo jabá do MBA deixa eu só olhar aqui uma coisa aqui com vocês no MBA tem uma parada que eu acho que é importante pra quem tá querendo fazer e eu também já tô tirando, já adiantando pra quem já fez matrícula, inclusive agradeço vocês galera para quem já fez matrícula. Inclusive, agradeço vocês, galera, que já fizeram matrícula e que vão participar aqui com a gente. Tem algumas coisas que eu acho que valem, que são importantes qualquer desenvolvedor entender e que eu acho que no MBA, esse cara ajuda bastante. O que acontece? Nós, desenvolvedores, a gente tem um problema muito grande de entender banco de dados. Tá? E por que que eu tô dizendo isso? Quando a gente entende banco de dados direito, a gente começa a entender que, por exemplo, um cáfica ele consegue atuar como um banco de dados. Entende? E quando você começa a entender esse tipo de coisa, uma coisa vai chamando a outra. Por exemplo, aqui, e era importante, eu estava com isso na cabeça, inclusive do MBA, por conta que, por exemplo, quando a gente cai, por exemplo, aqui no módulo de Kafka, quando a gente cai no módulo de Kafka, a gente acaba entrando exatamente nesses pontos de comunicação em tempo real porque o que o Kafka faz também é comunicação em tempo real por conta do Kafka Streams e aí você começa a entrar em problemas que começam a ficar um pouco complexos de acordo com o tipo de dado que você quer trabalhar. Vou dar um exemplo aqui para vocês. Se eu recebo uma mensagem duplicada, tipo, pagamento aprovado duas vezes da minha compra, o que acontece? Ou, se eu mandei uma mensagem para você e você não recebeu, o que acontece? Se eu mandei uma mensagem para você e você não recebeu, o que acontece? Se eu não dou uma garantia de entrega da mensagem para você, o que isso significa? Que você não tem certeza que eu não tenho certeza que você recebeu. Ou você não tem certeza que eu consegui enviar. Você entende qual que é o problema? E aí a gente começa a entrar numa seara do tipo, o quão importante são as mensagens que vão ser enviadas. Isso, tanto no WebSocket, com o SSE, ou com o sistema de mensageria. Entendeu? Por que eu estou dizendo isso? Vamos imaginar que eu vou mandar um trilhão de mensagens para você. Imagina que eu tô no Uber. E o Uber, que se eu não me engano, inclusive, usa a Kafka, o que que ele faz? A cada tanto tempo, ele fica mandando a posição do cara, certo? Se eu perder uma dessas mensagens, eu vou gerar um estrago muito grande pro sistema do Uber? Na opinião de vocês? Perdi uma das posições. Nesse caso, não. Porque é constante, né? Exatamente. O que que acontece nesse caso? Nesse caso, eu tô prezando muito mais pela velocidade, o throughput que eu tenho, do que necessariamente em garantir que a mensagem chegou. Por que que eu estou dizendo? Porque se para cada mensagem que eu enviar, eu ter que receber uma confirmação para eu falar, ok, ele recebeu, vai ser mais lento. Você concorda comigo? Faz sentido isso que eu estou dizendo, né? E as coisas mais importantes de quando a gente está falando em comunicação entre sistemas de resiliência é garantia de entrega e garantia de recebimento quando eu envio uma mensagem eu posso pedir uma garantia de entrega, para eu ter certeza no meu sistema e anotar o Alex falou que recebeu entendeu? mas eu tenho níveis e são através desses níveis que a gente tem que parar de tomar decisões que acabam sendo inocentes, tá? eu vou dar um exemplo aqui, apesar de a gente estar falando em tempo real, cá fica ainda a gente fala em tempo real, daqui a pouco eu já volto aqui, é o seguinte, imagina aqui, mandei uma mensagem pro Alex, mandei uma mensagem pra ele, e eu não pedi confirmação, o que que significa? Significa que eu consigo mandar muito mais mensagem pra ele, já que ele não precisa confirmar. Agora, se eu pedir uma confirmação pro Alex, o que que vai acontecer? O Alex aqui vai ter que falar, Wesley, recebi. E daí ele vai ter que me retornar aqui falando, olha, recebi. Tá? E daí eu vou anotar que o Alex mandou e eu tive mais garantia. Mas eu tenho um outro problema aqui, sabe qual é? O Alex ele representa um broker aqui. Sabe o que pode acontecer? Pode acontecer o seguinte. Eu mando a mensagem para o Alex. O Alex fala que recebeu a mensagem, mas daqui a pouco o cluster dele foi destruído. O que que acontece nesse momento? A mensagem é perdida do mesmo jeito. Vocês concordam comigo? Ele recebeu, confirmou, mas logo em seguida ele morreu. Acabou. Ferrou. Eu posso pedir uma garantia de entrega maior ainda. Eu posso falar, Alex, eu vou mandar pra você a mensagem. Você vai gravar no seu lugar. Você vai replicar essa mensagem nas partições que você precisa. Esses caras vão falar que essa gravação foi feita. Aí que você receber a confirmação de todo mundo, você me manda falando que está tudo ok. Esse é o tipo de garantia mais forte que eu posso ter, porque eu tenho a garantia de que a mensagem for gravada tanto no broker principal quanto nas réplicas. Entendeu? Agora, tudo tem o preço. Sem garantia de entrega, eu mando mais mensagens. Com a garantia de entrega pelo líder, eu tenho uma latência maior. E se eu tenho garantia de entrega pelo líder e pelo follower, a minha latência ainda é maior, porque eu preciso disso. Tudo tem o seu preço. Muitos casos, o Uber é fire and forget. Mandou e dane-se porque se eu perder uma posição ou outra, eu tô nem aí. Tô chutando isso, tá, galera? Eu não trabalho no Uber. Não sei como é que ele trabalha. Mas eu tô falando algo meio que de bom senso. Diferente de uma transação bancária. Aí, eventualmente, eu quero ter todas as confirmações, por exemplo. Entendeu? Então, esse aí é um ponto importante para vocês levarem em conta. Então, por que eu estou falando isso em relação ao MBA? Porque aqui, o conteúdo programático me ajuda a dar aula, no final das contas. A gente entra nessa parada. E tem uma parada que a gente chama de indepotência. O que é a indepotência? É você garantir que mesmo você receba uma mensagem duplicada, você vai processar essa mensagem apenas uma vez. Se eu receber dez vezes a mensagem um, eu vou descartar as outras nove vezes e processar só uma vez. Tá? Então, essa que é a ideia quando a gente acaba trabalhando, entendeu? E tudo isso, pessoal, muda o jogo. Você concorda que, cara, essa parada é muito louca porque esse envio de recebimento de coisa é mais ou menos assim, enviar mensagem com parâmetro 1, 0, 1 ou 2, tipo isso, no Kafka. Sacou o que eu estou dizendo? Significa que se você, ah, peguei lá no GPT e ele gerou para a minha implementação e aqui tem um parâmetro 0, eu nem sei, mas está funcionando. Cara, você está no Fire and Forget e não pediram garantia de entrega nenhuma. Você entende o buraco negro que você pode entrar numa decisão porque você não tem profundidade naquilo que você estava estudando ou que você estava aprendendo. Entendeu? O RabbitMQ tem a mesma pegadinha. Qual que é a pegadinha do RabbitMQ? Quando eu leio uma mensagem, por padrão que você vai olhar, vai ter um negócio chamado auto-ack. O que significa? Só de eu baixar a mensagem, essa mensagem já é descartada da fila. Mas se eu baixar a mensagem e eu travar, eu nunca mais vou ler essa mensagem. Então o que você faz? Você não faz o auto-ack. Você vai fazer o hack manual. Ou seja, eu vou ler a mensagem, vou processar, assim que eu processar, eu dou um hack e aviso o RabbitMQ pra remover a mensagem. Vocês entendem, galera, que o detalhe do detalhe aqui muda o comportamento completamente do sistema. Você entende que... Entende por que a gente tem que ter profundidade no que a gente está pensando? Quem aqui nunca tinha trabalhado e nunca tinha pensado em garantia de entrega e garantia de recebimento? Porque são dois pontos importantes de onde a gente está falando em resiliência. Entende? E aí você vai usar o Kafka, vê um parâmetro lá, nem sabe o que é, ou deixa um default, e o comportamento daquilo é completamente diferente. Ou ele vai ficar muito lento, muito rápido, perdendo mensagem ou gravando mensagem que você não precisava gravar. Entendeu? Eu só sei porque eu vi no curso seu, do Full Cycle. Aí, show de bola, meu amigo. Mas, pessoal, o que eu quero dizer com tudo isso, tá? Que quando a gente começa a trabalhar como pessoas profissionais e não vibe coders vamos dizer assim a nossa diferença tá a saber se você vai usar um 0, 1 ou 2 tá na diferença em quantas partições eu vou colocar num tópico entendeu? e isso muda o tipo de profissional da água pro vinho entendeu? fala meu querido a gente falou bastante que o Kafka o Revit, eles tem a resiliência deles, eles sabem se virar com os problemas e se resolvem. E quando... Quais estratégias a gente poderia usar no caso de eu receber uma mensagem, essa mensagem ela deve ser processada, mas por algum motivo alheio a todo esse ambiente, alguma coisa falha me fala, o que falhou? pode ser qualquer coisa um serviço que eu tenho que por exemplo, eu recebo uma mensagem eu tenho que fazer algum processamento tenho que consumir algum serviço alguma coisa não pode acontecer naquele momento não tem problema nenhum você não dá baixa na mensagem e daí essa mensagem você pode ler novamente e tentar processá-la novamente existe alguma estratégia assim de quantas vezes eu tento cara, aí vai depender muito da sua estratégia que você quiser, entendeu por exemplo, o Kafka você consegue fazer você consegue ver de onde ele parou toda vez que você voltar, ele vai continuar de onde ele parou toda vez que você voltar, ele vai continuar de onde você parou, por exemplo ou você pode falar, eu quero continuar a partir da mensagem número tal e aí ele vai, o RabbitMQ por exemplo, e dá pra fazer estratégias parecidas, ele tem coisas chamadas como Dead Letter Queues o que que acontece? A mensagem caiu pra uma fila, deu pau aqui no processamento, automaticamente essa mensagem cai numa outra fila, de mensagens que não conseguiram ser processadas, e daí eu boto um worker lá tentando entender por que aquelas mensagens não foram processadas. Não foi de novo? Ela volta. Ou eu posso fazer, não foi processada essa mensagem, beleza. Daqui eu boto um timeout e depois de novo eu jogo a mensagem pra fila de novo pra eu tentar reprogramar. E eu posso falar, tenta três vezes. Se não deu, vai pra uma dead letter queue. E daí eu pego essa fila, pego um programa de análise de logs, entendo aquela mensagem, entendo os logs e entendo olha, o formato do JSON estava errado e por isso que não estava processando. Então eu consigo ter essas estratégias, tá? Tá. É que a gente falou um pouco ali, vocês falaram um pouco ali daquele negócio de, eu consigo ter uma ordenação de processamento em fila e quando a gente pensa num cenário de falha, isso dá um baita de um problema, né? falha, isso dá um baita de um problema, né? Dá. Cara, trabalhar de forma sequencial é difícil, principalmente porque o que a gente busca com comunicação assíncrona é processamento paralelo, né? Mas não dá, se você precisa de ordem, o processamento paralelo ele não vai conseguir funcionar naquele caso. Então você tem que ver caso a caso. Mas, novamente, Wagner, o importante é que você tem consciência disso. Entendeu? O problema é uma pessoa que não sabe que esse problema existe. E aí ferrou. Não, show de bola. Sacou? Tudo que eu estou trazendo aqui para vocês, pessoal, o importante aqui não é você sair codando com o Kafka. A partir de agora, com certeza, muitos de vocês já vão estar ligados em garantia de entrega, garantia de recebimento. Um parâmetro simples pode mudar o comportamento completamente dos seus sistemas de mensageria e você pode mesmo perder mensagem, gastar mais disco, ficar mais lento. Tudo simplesmente por conta de um único parâmetro. E, novamente, essas coisas que diferenciam um profissional que vai conseguir trabalhar numa empresa e vai fazer diferença e não vai fazer merda. A realidade é essa, né? Entendeu? Então, esses tipos de informações, caras, anotem muito aqui pra vocês. O que eu ia falar? Outra coisa que estava também aqui no lance do MBA que eu queria falar, que era a parte de arquitetura baseada em serviço, coreografia e orquestração de microserviços, tá? Isso aqui é algo que a gente fala e que a gente prega bastante e é importante vocês entenderem que isso acaba acontecendo no processo de comunicação, tá? Alguém aqui sabe a diferença de coreografia e orquestração? Tem uma galera que manja, tem uma galera que não manja, tá? o lance é o seguinte, pessoal o que que acontece com micro serviços? eu tenho um micro serviço esse, com esse com esse, com esse, com esse o que que pode acontecer? Com esse, com esse, com esse. O que pode acontecer? Eu posso receber uma chamada que vai fazer uma chamada para esse microserviço. Aí vai ter uma fila. Aí esse microserviço vai mandar para essa fila. Aí essa fila vai passar dados para esse cara e para esse cara. Aí esse cara vai chamar esse cara. Aí esse cara aqui vai chamar esse cara. E esse cara aqui, ele pode bater nesse cara, que vai dar mais uma resposta para esse cara aqui. Essa parada acontece naturalmente no ambiente de microserviços. Ou seja, é coreografia. Um microserviço vai chamando o outro conforme a necessidade que vai acontecendo. E isso a gente chama de coreografia. Basicamente é isso. Um chama o outro, que chama o outro, que chama o outro. Não existe uma ordem de como que as coisas estão chamadas, sendo chamadas. Elas simplesmente, elas organicamente, vamos dizer assim, elas acabam acontecendo, tá? Na maioria dos casos, você vai trabalhar dessa forma, tá? Agora, o que que acontece? O Rafael colocou, coreografia é errado ou padrão de projeto? Não deveria estar tudo em fila? Não necessariamente, cara. Coreografia é a chamada desordenada de microserviços, independente se tem fila ou não. O ponto é que existem situações que isso aqui não funciona. E aí a gente entra num caso que a gente chama de orquestração. O que que um... orquestração. O que que um... O que que um maestro faz? Ele orquestra alguma coisa. Então, eu tenho micro serviço 1. Aí eu tenho micro serviço 2. Eu tenho microiço 3. A orquestração vai falar, microserviço 1 vai para cá. Após isso acontecer, vai ser feita uma chamada no microserviço 2. Após essa chamada, vai ser uma chamada no microserviço 3. Se deu um erro aqui, eu vou fazer um rollback aqui pra mim. Esse micro serviço 1 vai saber que tive um erro. Ele vai fazer um rollback aqui. Vai fazer um rollback aqui. Vai fazer um rollback aqui. Ou seja, eu quero garantir a ordem, não é processamento da mensagem, é a ordem do workflow é processamento da mensagem, é a ordem do workflow, é o fluxo que vai ser feito. Vou dar um exemplo. Fiz uma compra, tá? Eu só posso fazer o processo de shipping para enviar a minha compra se eu tiver a nota fiscal. Então, eu tenho a compra, aí eu tenho que emitir a nota fiscal. Aí, se eu emito a nota fiscal, eu consigo fazer isso. Depois, se eu fizer isso, eu tenho esse outro cara. Então, eu tenho todo esse fluxo que eu tenho que seguir. Se eu não conseguir emitir a nota fiscal, eu volto e cancelo a que seguir. Se eu não conseguir emitir a nota fiscal, eu volto e cancelo a minha compra. Se eu emitir a nota fiscal e chegou aqui no depósito e pegou fogo no depósito, ele vai falar não consigo fazer a entrega. Então o que vai acontecer? Ele vai voltar e eu vou ter que cancelar a nota fiscal e falar pra esse cara aqui que a nota fiscal foi cancelada. Galera, isso aqui é um trampo do cão. Existem patterns que fazem isso. Um pattern super conhecido é chamado de saga pattern. É um cara que faz isso. Existem diversas soluções que resolvem hoje em dia esses tipos de problema. A própria AWS tem lá o AWS Step Functions. Ele ajuda muito para fazer esses fluxos acontecerem de forma ordenada, por exemplo. Então, em determinados casos, você não pode trabalhar assim. Porque, de repente, eu estou emitindo a nota, mas o caminhão já está carregado, já está fazendo a entrega e a nota ainda estava sendo processada. Então isso aqui acaba não existindo. Então esses são pontos que são importantes para a gente trabalhar. O event sourcing, eu acabei falando para vocês, né? A Kafka pode ser uma alternativa para você também trabalhar ali com a parte de event sourcing e tudo mais. E lembrando, tá, pessoal? Não vou deixar de fazer jabá, tá? Pessoal, escaneiem esse QR Code agora, enquanto eu bebo uma água. Vou pedir para o Leonan também colar o link do form aqui para vocês. Você preenche esse form. Vai preenche esse form. Vai preencher seu nome, e-mail, aí depende se vai aparecer seu telefone ou não. Você preenche esse form. É um segundo. A gente vai entrar em contato com você. Entender seu momento profissional. E aí, se fizer sentido, você consegue entrar nesse MBA. A grande oportunidade que tem agora é que a gente está em pré-matrícula quando a gente abre a matrícula o valor volta a ser o valor original, você consegue entrar na turma de junho então você tem um tempinho aí pra se planejar e você aí tem, eu acho que se eu não me engano, em torno de 3 mil reais de desconto pra entrar nesse MBA, a gente consegue parcelar, dá pra parcelar no boleto, dá pra parcelar acho que até em 18 vezes, dá pra parcelar na recorrência, tem diversas formas, e cara, é um curso que ele vai te ajudar a pegar todos esses conceitos, porque isso é ensinado com aulas com caras tops da vida, mas também vai te dar a oportunidade de a gente ter aulas como essa, que a gente faz no Zoom toda semana. E, óbvio, se você não puder participar, você pode assistir a gravação dessas aulas, entendeu? A gente não bota TCC, trabalho de final de curso, que você vai ter que fazer monografia, nada disso. A nossa ideia aqui é que você consiga aprender de verdade e conseguir entender como que as grandes aplicações são desenvolvidas, mas por um aspecto muito importante no lado da arquitetura de software e na arquitetura de solução. Então, isso aí é um ponto bem interessante, tá, galera? E tem os caras fodões aqui que têm participações especiais, dão aula, participam fazem mentoria então vale a pena você entrar, então preenche esse formulário sem compromisso nenhum dê a oportunidade pra você escutar e entender melhor o programa pela nossa equipe pra você conseguir tomar uma decisão, tá, então eu acho que vale a pena pelo menos você preencher sentir a ideia a vibe, né, você e conseguir ter esse desconto que a gente tá querendo dar aí pra vocês beleza? maravilha galera show de bola meu povo então tem bastante coisas aí. Em relação aos valores, se tem gente perguntando, tem uma tabela de preços grande, entendeu? Porque depende da forma de pagamento, do tipo de pagamento, do período que você está contratando. Por isso que eu digo, entre em contato com a nossa equipe, porque tem diversas formas, diversos preços, baseado, inclusive, na sua forma de pagamento, tá bom? Então, preencha aí, galera, porque, assim, é um programa que a gente está melhorando ao longo do tempo, entendeu? E cada vez a gente está intencionalmente trabalhando muito nesse formato que a gente está usando hoje aqui em dia, tá? Que é Zoom, cara a cara, tirar dúvida, mentoria, trazer especialista, fazer breakout room, porque esse tipo de coisa não é um GPT que vai te ajudar. Você não necessariamente você vai ter, sei lá, uma palestra com a Loiane, com o Elemar, com o Albert da Microsoft, com o Fernando da Google, com o Juliano do Mercado Livre. Essas pessoas têm experiências e backgrounds diferentes e às vezes até visões do mesmo assunto, com visões diferentes e que eles mesmos podem não concordar. Mas o interessante é você ver visões diferentes de pessoas diferentes com backgrounds diferentes, tá? Então, isso aí é um ponto importante aí pra vocês verem também. Leona, coloca o link do MBA também aí pra eles, tá? Tem desconto pra quem já é aluno do Full Cycle? Normalmente a gente dá desconto sim, tá, pessoal? Se você já é aluno nosso, entra em contato sem dúvidas, porque a gente consegue condição de especial pra quem é aluno, tá? Sem dúvidas. Maravilha? Galera, pra gente ir pra... Caminhando um pouco pro nosso final aqui, eu quero falar de mais caras um pouquinho mais focados na parte de IA agora, tá? Que é algo que não dá mais pra IA agora, tá? Que é algo que não dá mais pra ser ignorado, tá? E que eu vou, que eu quero trazer aqui sempre pra vocês. Então, seguinte, hoje em dia, quando a gente tá falando em inteligência artificial, existem diversas formas, diversos protocolos, eu vou tentar trazer aqui três protocolos eu vou tentar trazer aqui três protocolos ou formatos de comunicação que hoje em dia estão consolidadas e uma delas está se consolidando é uma grande aposta, mas aparentemente vai dar bom tá em relação a essa parte de IA primeira coisa é o que a gente chama de Function Calls. Alguém já ouviu falar em Function Calls quando a gente está falando em IA, galera? Quem aqui já ouviu falar em Function Calls? Acontece o seguinte, pessoal. Quando você está num modelo de inteligência artificial, que tem o seu LLM, você pode, no lado da sua aplicação, que no lado da minha aplicação, eu criar funções que podem fazer coisas personalizadas. Tipo, função externa, uma chamada de API. Só para dar um exemplo aqui para vocês. E o que acontece com essas functions calls? Eu, aqui, eu gero uma especificação das funções que eu tenho aqui para mim. Tá? E qual é o meu objetivo aqui? das funções que eu tenho aqui para mim. Tá? E qual é o meu objetivo aqui? Quando eu faço uma chamada em linguagem natural para a minha LLM, a minha LLM, o que ela vai fazer? Ela vai entender quais funções ela tem disponível. Tá? O que faz sentido no contexto que a pessoa está escrevendo. Porém, o que acontece nesse caso? Como a IA entende meio que a assinatura dessa função, o LLM, o modelo, o que ele vai fazer aqui para mim? Ele vai gerar, vamos dizer assim, o JSON com as informações do usuário e dar para o meu client. E o meu client, nesse momento, a minha aplicação, ela chama a função. Vocês conseguiram entender o que eu estou querendo dizer, galera, com isso? Não é a LLM que faz a execução da minha função. A LLM, ela apenas formata os dados, formata o payload, e eu escolho se eu vou executar essa função ou não então isso aí é um ponto importante tem uma diferença muito grande de eu falar pra você, olha aqui tá os dados caso você queira chamar esse cara nesse contexto, tá aqui a chamada que você vai perceber, o cara passou o e-mail o nome e o telefone, então eu estou te mandando nesse formato porque talvez faça sentido você fazer um contato com ele. E daí, a minha função, baseado nos parâmetros que ela passou, eu posso olhar, ah, o cara tem 10 anos de idade. Então, não faz sentido eu chamar esse cara. Então, eu não vou executar essa função. Entende o que eu tô querendo dizer? Ou seja, a responsabilidade de fazer a chamada é minha. A IA só junta os dados e ela infere qual função eu deveria chamar naquele contexto. Ou seja, ela entende a minha intenção, baseende a minha intenção, baseado na minha intenção, ela vê a lista de funções que eu tenho que faça mais sentido naquela intenção, e ela formata o payload daquela função da forma que eu expliquei pra ela. Aí ela vai mandar isso pra mim, aí eu vou analisar os parâmetros dessa função e vou ver se eu executo ou não. Eu posso falar, não quero executar porque o cara falou que ele tem, não sabe programar e quer fazer o MBA. Então eu não vou fazer essa chamada. Não vou adicionar ele na minha agenda pra eu entrar em contato com ele. Você entende que quem manda aqui nesse cara sou eu. Eu crio a função, eu escolho se a função deve ser executada. O LLM entende a minha intenção, ele formata os dados no formato da minha função, mas ele não executa nada. Ok? Fez sentido? O Elias está falando será que isso seria um exemplo de function call quando eu peço pro GPT gerar um PDF da conversa? Cara, não dá pra saber como é que ele trabalha internamente, mas quando eu falo gere um PDF da conversa, ele entende a sua intenção que é um PDF. Ele tem os dados do PDF, então ele vai formatar, mandar todos aqueles dados com o payload, e provavelmente vai mandar para o chat EPT, estou dando o exemplo, o client, falar, aqui tem um PDF que esse cara pediu. E daí o meu client pode falar, olha, esse PDF é muito grande, eu não consigo gerar, não vou chamar essa função para gerar o PDF. Entendeu? Ou eu vou executar essa função. Então, isso aí é um ponto importante para vocês entenderem que essa pegada de function calls tem diferença entre MCP. Eu estou falando isso porque tem gente confundindo function calls com MCP. A OpenAI, se eu não me engano, ela é a pioneira em ter feito isso aqui para trabalhar com function calls. Isso aqui tem no SDK dela, tem como você trabalhar, não é nada difícil. O Gemini, se eu não me engano, a partir da versão 1.5 também trabalha com function calls e tudo mais, tá? Então, esse é um cara que é importante você saber nos dias de hoje, quando você for desenvolver sistemas com IA, você saiba que se você trabalhar com function calls, você tá no controle. Ok? Maravilha? A function call seria um prompt? Não. A function call é uma chamada de função personalizada que eu quero trabalhar. Entendeu? Eu consigo executar a chamada de uma API, criar um evento cadastrado, salvar num banco de dados, mas quem pega as informações para preencher os parâmetros dessa função é o meu modelo. Mas não é o meu modelo que está executando aquela função. Ok? Oi? Oi? Eu perguntei esse negócio. Na prática, você teria um client aqui do seu lado que executaria a function call, bate na IA, a IA retorna os parâmetros lá, sei lá, você pediu alguma coisa pra retornar o nome, alguma coisa, ele retorna lá um JSON com o nome. É mais ou menos isso. É tipo assim, o fluxo é mais ou menos... Você usa internamente. O fluxo é mais ou menos... Você usa internamente. O fluxo é mais ou menos assim. Fala assim, quero saber a cotação do dólar para real. Aí eu tenho uma função aqui, cotação, dólar e moeda. Certo? Basicamenteeda. Certo? Basicamente isso. Aí o que acontece? Quando eu escrevo isso, a minha LLM sabe que eu tenho algumas function calls cadastradas. Ela vai falar, bom, baseado no que esse cara está pedindo, existe uma função de colotação do dólar e eu sei que tem um parâmetro moeda e eu sei que a moeda é real. Aí o que ele vai fazer? O meu modelo vai fazer o seguinte. Ele vai pegar, vai gerar um JSON aqui no formato que essa função precisa, com os dados da função, e vai passar aqui para a cotação do dólar. O que eu vou fazer nesse momento? Eu vou fazer a cotação do dólar. E o retorno dessa cotação do dólar, eu posso mandar para a LLM de volta. Ok? Basicamente é isso. Mas, como essa função sou eu que criei de forma personalizada, eu posso falar, não quero dar a cotação do dólar depois da meia-noite. Ou eu posso até falar, eu vou dar a cotação do dólar, mas além disso, eu vou adicionar algumas outras informações que eu quero para que a IA tenha ainda mais contexto com o resultado que ela quer trabalhar. Mas você consegue perceber que eu estou no controle aqui, a IA, ela só me dá os parâmetros. Ela entende a intenção, ela vê o meu cardápio, ela só me dá os parâmetros. Quem executa e escolhe a execução pela lógica de negócio sou eu. Entendi. Legal. Fez sentido, galera? Dá um esquema, né? Ô, Wesley. Oi. Trazendo um cenário mais assim, mais padrão, a Alexa, ela utiliza a função call? Cara, eu não tenho ideia. Na realidade, a Alexa, ela não trabalha com... Não sei. Absolutamente eu não sei. Porque a infraestrutura, a estrutura da Alexa é diferente. A gente até pode, vamos dizer assim, fazer uma analogia. Agora, tecnicamente falando, eu não tenho a menor ideia qual a tecnologia que a Alexa está usando. Entendeu? Wesley, posso falar aqui rapidinho? Pode. Com licença. Então, eu sei assim, a Alexa, eu sei que saiu a Alexa Plus que já está com o LLM embarcado, tá? Mas a Alexa anterior da arquitetura é só aquele conceito lá de casa inteligente, das chamadas de APIs, né? É porque, na realidade, você dá as skills. E as skills da Alexa, É porque, na realidade, você dá as skills. E as skills da Alexa, no final das contas, é o cardápio das funções que ela pode fazer. Entendeu? Mas, não necessariamente num modelo, num LLM que a gente está acostumando usar agora com OpenAI e etc. Entendeu? Mas a Amazon já faz um tempinho... Agora, dessas evoluções, provavelmente... Evoluiu. Provavelmente, todos esses caras vão pra... Vão começar a ir pra esse nível, entendeu? Olha, eu acho que a Amazon demorou, viu? Pra lançar a LLM embarcada, viu? Depois de toda essa onda crescente de LLM, né? Pois é. É que deve ser caro pra caramba, né? Bom, eu não sei. Honestamente, cara, eu nem me atrevo porque eu sei que a forma como a Alexa foi criada com os skills, é mais ou menos como se fosse uma function call você tem um cardápio de habilidades que ela tem e ela pode chamar eu acho que é uma analogia mas basicamente essa é a ideia de function calls por que eu estou falando isso aqui galera? porque tem muita gente confundindo isso com o tal do MCP e são coisas diferentes e complementares. Eu posso trabalhar com Function Calls e eu posso trabalhar com MCPs. Então, isso aí é algo realmente... É complexo. Mas, por exemplo, se você for utilizar padrão, sei lá, trabalhar com OpenAI, você vai ver que no SDK você consegue registrar funções, você consegue personalizar suas funções, e em seguida você consegue pedir para a IA fazer a chamada dessas funções e você decide, baseado nos parâmetros, se você vai fazer ou não. Ok? Ficou claro para todo mundo isso, galera? A minha Siri está falando, tá com ciúmes que eu tava falando da Alexa a minha Siri tá respondendo aqui no meu relógio show? quem é a Alexa né? pois é agora a gente tem um outro cara que é o MCP tá? o MCP o MCP a pegada dele é outra MCP é Model Context Protocol um protocolo de modelo de contexto a diferença em relação a Function Call e um MCP ela na realidade, ela acaba sendo grande por conta dos níveis. O Model Context Protocol, no final das contas, ele permite que eu tenha um host, cursor, por exemplo. Ele permite que eu tenha um MCP client e ele permite que eu tenha um servidor aqui. O que que acontece nesse caso aqui? Quando o host começa a realizar as operações, o meu modelo consegue entender a minha intenção, ele consegue ter a lista de cardápios dos servidores MCPs que eu tenho, e ele escolhe qual a ferramenta que ele pode chamar baseado naquilo. E aí, ele faz uma chamada, através desse client, para um servidor externo. Ou seja, não é dentro do meu próprio software. Esse cara aqui está dentro do meu próprio software. Esse cara aqui está fora do meu próprio software. Ponto importante aqui é que o MCP ele tem uma parada que a gente chama de tools que é a coisa mais comum que a gente acaba utilizando no dia a dia. Que no final das contas, o que que ela faz? Ela consegue realizar ações em servidores. Então eu tenho uma tool que vai fazer eu criar uma PR no GitHub. Eu tenho uma tool que vai fazer eu criar uma PR no GitHub. Eu tenho uma tool que vai conseguir eu aprovar um code review. Ou seja, eu estou realizando ações. E quem faz essa chamada aqui é o meu modelo, uma vez que ele consegue se conectar com uma lista de servidores do MCP. O outro ponto é que o MCP ele tem uma outra parada aqui também, chamada Resources. E os Resources aqui do MCP, o que que eles fazem no final das contas? O Resource é uma fonte de dados que eu posso usar para trazer informações para a minha LLM. Esse resource, quem controla a chamada dele não é o modelo, é o meu host. Ou seja, um pouco parecido com isso aqui. Na realidade, o que eu consigo fazer é o seguinte, imagina que eu estou num sistema de A, onde eu tenho a minha lista de produtos, eu tenho a documentação do meu sistema, eu tenho um monte de coisa. E daí eu estou na parte de cadastro de produtos, na minha parte onde eu quero ver as documentações com as minhas listas de produtos, e o cara está perguntando, ó, eu quero a lista de produtos. Aí eu sei, eu como software, eu sei que eu tenho um resource chamado lista de produtos com preços. Aí eu consulto esse resource e disponibilizo pro modelo. Então quem tá fazendo a chamada desse resource não tá sendo o modelo, não tá sendo o LLM, tá sendo o meu host. Entendeu a diferença que eu estou querendo dizer? Quando eu estou trabalhando com tools, o meu modelo faz a chamada para o meu servidor. Quando eu estou falando em resources, é o meu sistema, sabe que eu tenho aquele recurso, eu acesso o servidor MCP para trazer esse recurso para eu utilizar ali para mear. E por último, eu tenho o cara que é chamado de prompt, que são listas de prompt que eu utilizo e reutilizo o tempo inteiro para eu trabalhar no dia a dia. E quem escolhe essa lista de prompts aqui é o usuário eu Wesley vou utilizar a minha, eu quero ter uma lista de prompts pra eu gerar propostas comerciais então eu seleciono esse prompt escolho recursos da minha tabela de caras, a gente deu uma talk, fala Leonan semana passada só sobre MCP. Eu mostrei na prática, tools funcionando, resource funcionando, prompt funcionando, as três funcionando simultaneamente, gerando propostas, modelos de negócios e coisas desse tipo, utilizando cada item do MCP. O problema de hoje em dia é que a maioria das pessoas, quando falam em MCP, está pensando só nesse cara aqui, porque é esse cara que aparece no cursor na hora de você trabalhar. Mas quando você desenvolve aplicações com IA, o MCP provê aqui para a gente resources e prompts que vão ser uma mão na roda para você ter fonte de dados pra você utilizar a fonte de dados pode ser uma imagem ela pode ser um texto ela pode ser um pdf ela pode ser qualquer coisa e isso eu consigo jogar ali pro meu modelo eu tenho essa opção eu consigo acessar o mcp server que me dá esses resources. Então, isso aí é um ponto importante para que vocês consigam entender. Então, hoje em dia, o MCP está tendo uma atração gigante. A Google e a OpenAI estão adicionando suportes também a MCPs nos modelos deles. E eu fiquei muito feliz com isso, porque quem fez isso foi a Antropic e a minha maior dúvida é será que a Antropic consegue gerar um movimento que vai fazer a própria OpenAI aceitar a falar utilizando com MCP? Entendeu? Então, isso aí é uma coisa extremamente importante e é um marco importante que a gente está trabalhando aí. Isso aí é uma coisa extremamente importante e é um marco importante que a gente está trabalhando aí. A parte interessante, Wesley, que é o Flávio falando, é por conta de ser um protocolo. Então, você padroniza a comunicação. Acho que isso já facilita difundir a tecnologia. Exatamente. É que a gente chega num momento de A, que tudo está mudando, que o meu medo ali era a OpenAI criar o MCP dela entendeu? Aí você começa a ter muitas brigas desses protocolos e eu tô feliz pelo fato da OpenAI estar aderindo ao MCP, o Gemini está aderindo ao MCP E como é que você enxerga a questão da privacidade dos dados? Porque se o serviço você não paga, muitas vezes você é o produto. E até mesmo você pagando, muitas das vezes eles ainda usam os seus dados para treinamentos, etc. Então, às vezes você usa, tem dados sigilosos de negócio. Cara, aí depende muito. Se você está trabalhando como desenvolvedor com esses planos de negócio, né? Cara, aí depende muito, tá? Se você tá trabalhando como desenvolvedor com esses planos básicos, aí seus dados vão tá ali e acabou. Tá? Mas se você tá numa empresa que tem departamentos de compliance do Caramba 4, eles têm contratos com essas empresas, e esses planos enterprises, esses dados, eles acabam sendo sigilosos, não entram como treinamento, e tem toda uma separação ali, etc. O uso até através de API, ele tem essa privacidade um pouco mais forte, né? Cara, pra caramba, entendeu? Então, assim, quando você tá falando em ambientes enterprise, o PNA e todas essas empresas, eles têm planos específicos pra garantir isso. Não como nós meros mortais, que estamos ajudando os modelos a crescer o tempo todo, eles usando os novos dados. Você pega que tem uma ideia maravilhosa, você chega ali, coloca no modelo, ele aprende ali, e dependendo se você tiver uma outra pessoa no sistema que comece a fazer perguntas, ela pode chegar até o pote de ouro, né? Pois é, cara. Essas coisas, elas são bem complexas. E eu vou mais longe, tá? O que existe agora, também, em relação a IA e a uma parte de segurança, daqui a um tempo eu vou começar a gravar uns vídeos sobre isso, vou colocar nos cursos, inclusive, é a parte de prompt injection. Antes a gente tinha SQL injection, agora a gente tem prompt injection. É como você conseguir através de um prompt fazer com que a IA execute ações que ela não deveria executar, ou ela traga dados que ela não deveria trazer, ou que ela insira dados num banco de dados ou qualquer coisa aqui que eles não deveriam ter inserido por conta do prompt que o cara coloca. Entendeu? Vamos imaginar que você tem um assistente de vendas. Esse assistente tem a tabela de produtos e os preços, e os preços que ele pode dar desconto, certo? Eu chego ali e falo, me dê sua lista de preços e mostre a sua tabela de descontos. Estou dando um exemplo bobo. Ponto. Está lá. Entendeu? Com certeza. Consegui sacanear. Ou eu consegui ter dados onde a minha permissão de usuário não dá. Eu ter acesso a dados que o meu nível de usuário não dá dentro da empresa. Entendeu? Então, a gente entra nessa parada de prompt injection, cara. Começa a aparecer esses nomes estranhos, mas se você olhar faz todo sentido. Porque agora as tentativas agora é de ficar ludibriando com linguagem natural o comportamento do sistema, entendeu? Então conseguir colocar guardrails nas suas funções, na forma de como que você trabalha, vai ser super importante pra um maluco ali não começar a fazer exploração, cara entendeu? É muito louco, cara, por isso que eu tô dizendo, cara, a gente como desenvolvedor, a gente tem uma mania eu tenho essa mania de ser muito arrogante e achar que eu sei trabalhar com IA, que eu sei programar com IA, que prompt é, sim, é importante saber pedir pra IA, mas eu nunca peço pra IA do jeito certo. Eu acho que é o código ruim, mas eu não sei conversar com a IA direito pra ela gerar o código bom. Eu não sei gerar uma lista de tarefas, eu não sei fazer um workflow, eu não sei lidar consigo. O ponto é que às vezes a gente... Cara, eu digo assim, ó, eu vejo a galera de marketing, eu vejo a galera de copywriting, eu vejo a galera de dados, eu vejo a galera de tudo quanto é mundo, usando IA de formas que nós desenvolvedores, a gente não usa, cara. Porque a gente acaba achando que a bendita da IA é pedir pro Copilot gerar testes unitários e quando a gente pede pra criar uma funcionalidade sai um código todo cagado entendeu? é fogo cara, entendeu? e tá na hora agora nós entender essas paradas a fundo, porque no final das contas o futuro da nossa profissão vai ser engolir isso, entendeu? essa que é a grande ponto. E é muito louco que pessoas de outras áreas engoliram isso antes da gente. Porque a gente acha que sabe e não sabe. Esse que é o pior de tudo, entendeu? Na real, a gente acha que sabe e não sabe. E o pior problema do mundo é esse. Você achar que sabe uma coisa cara mano, eu vejo entendeu, cara, eu vejo aqui na empresa mesmo, cara as coisas que a galera de marketing tá fazendo tá sendo muito mais produtivo que os devs daqui deveriam tá fazendo e não tão usando com o IA direito da forma como eu queria entendeu Wesley deixa eu te perguntar um negócio não tá fazendo, não tão usando com o IA direito da forma como eu queria, entendeu? Ô Wesley, deixa eu te perguntar um negócio. Você acha que essa questão da inteligência artificial aí, todo o MCP, esse Function Cells, né, esse LLM, com essa produtividade que ela tem de fazer o front-end e o back-end, e pensando em low-code, por exemplo, um Apex, você acha o que seria mais produtivo hoje? Você utilizar uma IA dessa aí, ou você ter um Apex pra você produzir um sistema? Depende muito do requisito também, né? Cara, na real, você é desenvolvedor, meu amigo, o seu lugar é no editor de código, conversando com a IA, sabendo documentar, sabendo explorar, saber passar requisitos, criando documentação de contextualização sabendo trabalhar com os prompts certos, pros contextos certos entendeu? Porque assim a eu vou dar um spoiler aqui pra vocês deixa eu pegar aqui meu, rapidinho só pra passar por cima porque assim eu já vi o Apex, né? eu já dei uma olhada já vi o Apex, eu já dei uma olhada como funciona o Apex e eu vi que ele é assim, uma forma simplificada de você... Cara, você está falando Apex ou Codex da OpenAI? Não, não, o Apex é aquela é uma plataforma onde você consegue fazer low-code então você consegue arrastarcode. Então, tipo, você consegue arrastar um botão e ele é da hora. Então, cara, mas esse que é o grande ponto, Caio. Eu não sou contra isso de forma alguma, mas o grande ponto aí é o seguinte, cara. Se você é desenvolvedor e vai trabalhar em empresa grande, cara, raramente você como desenvolvedor e os problemas que você vai ter, você vai ficar resolvendo com o low-code. Porque o problema não está no resultado que ele gera. Você pode até pegar e gerar uma tela de um front-end para te ajudar, mas, cara, você vai pegar um front-end gigante, você tem que se aperar em componentização, ele tem que ter boas práticas, ele tem que ter documentação, ele tem que ter uma pancada de coisas que essas ferramentas elas não vão gerar. O grande problema do software é o software conseguir durar ao longo do tempo. Essas ferramentas entregam muito rápido, mas com alta complexidade, que ao longo do tempo ela não dura, entendeu? Nós, como desenvolvedores, a gente tem que ter guidelines, técnicas e etc. para não ficar dependendo desse tipo de ferramenta, entendeu? Esse é o grande ponto. Aquele gráfico que você desenhou no início, o Mocha representa muito bem. É bem isso. Depois eu posso até botar direito. Mas, caras, eu estou trazendo aqui de possibilidades só com prompts que mudam a sua vida. Documentação e design docs. TDE, TRD, PRD, FRD, User Stories, System Design, Low Level Design, Diagrama C4, Architecture Decision Records, RFC, Coding Standards, Code Review, Testing, CI, CD, Security, Runbook, Playbook, Infrastructure Design. Todos esses documentos agora, se você tiver o prompt correto, o assistente correto, você gera esses documentos de uma forma muito rápida, fácil e de forma decente, que vai estar na sua pasta docs, na hora que você for programar com o seu cursor, com qualquer ideia, a sua IA vai conseguir ler esses documentos e vai ter uma precisão muito maior na hora de tomar as decisões para desenvolver. Aí, para você implementar, você precisa saber explorar o problema que você vai estar trabalhando. Você vai precisar contextualizar para a IA. Você vai pedir para ela criar tarefas e planos de ação para que ela não saia que nem uma louca tentando fazer tudo ao mesmo tempo. Você vai ter que ter um workflow que vai falar para ela qual é a sua regra, qual é o seu processo de trabalho. Primeiro você vai fazer isso, depois você vai fazer isso, depois você vai fazer isso, depois você vai fazer isso, depois você vai fazer isso, depois você vai fazer isso. Como que eu faço o testing? Como que eu faço o debugging? Como que eu faço... Cara, pra cada cara desse, é um prompt diferente pra cada tipo. E aí a gente vai pra vários tipos. E aí, hoje em dia a gente cai nessa barreira por conta do tamanho do contexto. E por isso que ela não consegue fazer tudo de vez se você tem que realmente parafrasear para ela, né? Cara, tem o tamanho do contexto. Janela de contexto daqui para frente, cara, não vai ser muito problema, que só vai ficando aumentando, entendeu? Mas o maior problema é ela fazer uma tarefa depois da outra. Porque ela está fazendo uma tarefa, aí o que acontece? Você viu que ela escreveu um negocinho errado, daí você escreve assim, cara, você fez isso errado. Ela vai falar, ah, tá bom, deixa eu corrigir. Daí ela corrigiu e daí parou a tarefa que ela tava fazendo, entendeu? E ficou aquele tabu, era tarefa pela metade, daí seu código não tá mais compilando, daí ela continua, daí assim continua, daí ela pensa, continue mexendo. Cara, é uma loucura. E na hora que você começa a entender isso aqui, os tipos de prompts, como que você trabalhar, entender pra qual tipo de prompt que você vai usar pra cada situação com o IA, eu fiz várias tabelas, cara. Quando você usa cada tipo de prompt, pra cada tipo de coisa, o nível de resultado é outro, meu amigo. É outro. É simplesmente outro. Quando que eu uso isso? Quando que eu uso aquilo? Cara, o nível é completamente outro. Então, o que eu tô querendo trazer aqui pra vocês é desenvolvimento com IA, tá? É ter conhecimento sólido e é prompt. E esse prompt não é simplesmente como pedir. São muitas técnicas, são muitos prompts diferentes, são muitas situações. Eu criei um servidor MCP, eu vou gravar um vídeo no YouTube para mostrar para vocês, para dar um exemplo de servidor MCP, mais um exemplo de um servidor MCP, que por padrão usa sempre um prompt bom para desenvolvimento. Então na hora que você vai desenvolver, você chama o MCP, ele bota esse prompt e anexa junto com as suas tarefas. Você vai ver que só de usar isso, já melhora muito o seu processo de desenvolvimento com o Cursor, por conta de um prompt, entendeu? É muito louco esses tipos de coisa. E galera, para a gente fechar, eu quero falar de um outro cara que é importante e eu estou botando muita fé nele, que ele é chamado de A2A. Quem já ouviu falar em A2A? A2A. Alguém já ouviu falar em A2A? Aquele N8A, você ouviu falar já? Sim. Ferramenta de automatização de fluxos, consegue falar com muitas coisas. Ele fala com o MCP Server? Ele fala com o MCP Server, Ele fala com o MCP server, ele fala com qualquer coisa. Hoje em dia ele implementou MCPs. Mas assim, em mundo de desenvolvimento, ainda mais em grandes empresas, esse cara não vai escalar, entendeu? Você não vai depender... A aplicação da sua empresa depende de uma ferramenta externa completamente. E na hora de escalar, não vai escalar, ou você vai pagar A aplicação da sua empresa depende de uma ferramenta externa completamente. Vou dar uma olhadinha. E na hora de escalar, não vai escalar. Ou você vai pagar muito caro para ter nodes dedicados do N8n. Eu acho muito bom o N8n para fazer fluxo simples ou para fazer provas de conceito. Entendeu? Mas na prática, dia a dia, desenvolvimento, cara, eu não trabalharia com o N8n. Entendi. Tá? A8 cara, eu não trabalharia com N8N entendi tá A2A, quem sabe quem é esse cara aqui? A2A, tá? um protocolo da Google que é chamado de agent no Google Next, né? to agent, essa ideia é genial, é isso que eu quero trazer aqui pra vocês, Basicamente, esse protocolo, ele permite que agentes de A consigam falar com outros agentes de A em linguagem natural. Ou seja, eu crio um agente que consegue falar com outro agente. Qual que é o grande problema que nós temos hoje em dia? Existem diversos frameworks, diversas ferramentas pra você criar agentes de A. E esses agentes não conseguem se conversar. Entendeu? Porque eles são feitos de formas diferentes. Como que eu consigo criar agentes em diversas tecnologias, com diversas linguagens, com programações diferentes, com modelos diferentes, tudo diferente, e ainda fazer esses caras se comunicarem para executar tarefas que eu quero? Entendeu? E o mais interessante desse cara, que é criado pela Google, ele é um protocolo que faz com que um agente consiga falar com outro agente. Então, nesse caso aqui, a gente tem alguns conceitos, tá? Que a gente chama de... Nesse cara, que a gente tem o agente cliente e o agente remoto. O agente cliente, ele é o cara que é responsável pelo quê? Por fazer as solicitações das tarefas que a gente quer que o agente remoto faça. E o agente remoto, ele executa as tarefas solicitadas e retorna o resultado. Então, essa é a parada. Como que funciona esse cara? Tá? Dando uma visão geral aqui pra vocês. Nós temos uma área dele que a gente chama área de discovery. Tá? Como é que funciona essa área de discovery, descobertas? Eu tento identificar quais são as capacidades que aquele agente tem. Tá? Essas capacidades que aquele agente tem. Essas capacidades, elas são chamadas de agent card. Imagina que é um cartão de visitas meu, e eu falo nesse cartão de visitas tudo o que eu sou capaz de fazer. Eu pinto, eu bordo, eu faço elétrica, tipo isso. É o meu cartão de visitas. Esse agent card, normalmente, ele é um JSON, e ele fica numa URL chamada wellknown.agent.json. Nesse agent card, vai falar o nome, a descrição que esse cara faz, as URLs desse cara, processo de autenticação, e quais são as habilidades, as capacidades que esse agente tem de fazer. Tá? Então, esse é o primeiro ponto. Legal? Então, um é o primeiro ponto. Legal? Então, um agente fala com o outro, pra um agente falar com o outro, um agente vai ler o cartão de visitas do outro agente, pra saber o que aquele agente consegue fazer. Tá? A segunda etapa que a gente tem desse cara é a parte de gerenciamento de tarefas. Por quê? Porque quando um agente vai pedir pra um outro fazer alguma coisa, a gente acaba tendo uma tarefa, uma unidade de trabalho que tem status. Então ele tem submitted, quando uma tarefa foi pedida para ser feita, working, quando a gente está desenvolvendo, input required é quando eu mando uma tarefa para um agente e o agente fala, agora qual é essa informação? Eu preciso que você me mande mais dados. Daí ele preenche aquele input. Completed, quando foi completado. Failed, se falhou. Cancelado e unknown é quando eu não sei a merda que deu. Basicamente é isso. Mas a ideia das tarefas é, um agente pede uma tarefa para o outro agente. Essas tarefas é, um agente pede uma tarefa para o outro agente, essas tarefas têm status, e esses status podem inclusive solicitar input required, ou seja, eu preciso aguardar que o outro agente me dê mais informações que eu estou trabalhando ali para a gente. Agora, o importante é que esse cara aqui, ele tem algo que a gente chama de mensagens, ou mensagens barra partes, ou partes. Porque eu posso mandar essas mensagens em três formatos principais. Text part, que é um texto simples. File part, que pode ser arquivo, ou URLs, que vão ter arquivos. Ou data part, que são dados normalmente em JSON. Então, esses são os formatos de dados que a gente trafega aqui no A2A. Legal? No final das contas, a gente vai ter algo que a gente chama de artefato, o artifact. O que é o artefato no final das contas, galera? É o resultado final de saída gerado por uma tarefa que possui em partes. Então, eu pedi pra ele fazer aquela tarefa, ele fez aquela tarefa e o resultado daquela tarefa é uma imagem, mais um JSON, mais um texto, ou seja, é o output que o outro agente vai receber. Então, eu faço tarefas, essas tarefas circulam com mensagens, de partes de mensagens. E no final, que a gente tem isso acabado, a gente tem o artefato final, que é o resultado daquela tarefa acabando sendo desenvolvida. Como é que funciona, mais ou menos, a parte de comunicação? É bem parecido, em relação ao protocolo de comunicação com o MCP porque ele trabalha com o JSON RPC né, e uma coisa interessante desse cara, ele suporta streaming, então ele consegue trabalhar com tarefas longas, eu consigo deixar um agente plugado no outro agente enquanto o outro cara tá realizando a tarefa tá, e ele também permite com comunicação, eu eu consigo deixar um agente plugado no outro agente enquanto o outro cara está realizando a tarefa. E ele também permite, com comunicação, eu dar push notifications através de webhooks. Então, eu estou fazendo uma tarefa, algumas coisas têm que ser assíncronas, conforme ele vai terminando também, ele pode ir fazendo vários posts ali via webhooks para que o outro agente vá recebendo essas informações. Apenas um exemplo aqui para vocês de uma ideia mais ou menos de como é que funciona uma dessas mensagens aqui. Eu gerei aqui um JSON para vocês verem. Então, basicamente, eu tenho o JSON RPC 2.0, o ID1, o método é uma tarefa para enviar, o parâmetro que eu estou mandando, a mensagem, as partes, eu estou falando que eu tenho uma parte que é um text e o texto é por favor, os detalhes do MBA full cycle. E dados de metadata. Quando eu mando esses dados para o outro agente, o outro agente, ok, deixa eu fazer uma tarefa, a tarefa eu entendi que ele quer pegar os detalhes do MBA. Aí esse meu agente, ele pode fazer chamadas de API, navegar no site, pegar os detalhes, aí ele pode gerar ali no final uma tarefa como um artefato, né? E esse artefato é mandado para esse agente ter todas as informações. O mais louco de tudo isso, no final das contas, galera, é que se vocês perceberem o A2A, apesar de ele ser um protocolo de comunicação, esse protocolo, no final do dia, ele faz com que um agente fale com o outro em linguagem natural. Sacou o que eu tô querendo dizer? Por favor, dê os detalhes do MBA full cycle, cara. É assim que um agente manda mensagem pro outro, eles se comunicam como se fossem pessoas se comunicando. E quando eu tenho isso, eu posso ter por exemplo, que é o exemplo que a Google dá no repositório do A2A, eu tenho uma agência de viagens. Então, uma pessoa pede uma cotação para eu viajar pra Dubai. E daí, nessa cotação para eu viajar para Dubai. E daí, nessa cotação, eu vou pedir a cotação para um agente de passagem aérea, eu vou pedir uma cotação para transfer, eu vou pedir uma cotação de hotel, eu vou pedir uma cotação disso, eu vou pedir uma cotação de aquilo. Cada cotação são agentes diferentes. Tem um agente específico em reserva de hotel, eu tenho um agente específico em reserva de hotel, eu tenho um agente específico em passagem aérea, eu tenho um agente específico só em transfer, eu tenho um agente específico só em entretenimento e city tour, aí esses agentes eles fazem as cotações e vão mandando e aí eu tenho todo o resultado final, daí eu falo, ok, gostei faça uma reserva pra mim, aí cada agente vai fazendo essa resposta, vai trabalhando. E um agente vai podendo chamar outro agente que vai chamando outro agente. Vocês conseguem entender como é que essa parada vai? O nível que isso... O nível de possibilidade. Se você acha que MCP é uma parada foda, imagina quando você tem um trilhão de agentes se comunicando em linguagem natural com outros, fazendo um monte de tarefas. Sacou? Agora imagina que os softwares que a gente vai desenvolver vão começar a ser agentes no final das contas. E a gente vai precisar usar protocolos desse tipo para falar com outros agentes. Sabe aquele módulo, aquele microserviço? Talvez ele não seja um microserviço, ele seja um agente agora. Entendeu? Arquitetura baseada em agentes. Arquitetura agêntica. A gente vai começar a ouvir esses nomes. Entendeu? A gente vai ouvir cada dia mais AI Driven Development. Não é mais TDD, Test Driven Development. É AI Driven Development. Esses termos, todas as coisas vão começar a surgir, cara. Desenvolvimento modo agêntico, porque a gente vai trabalhar com agentes no Copilot, no Cursor, para sair desenvolvendo com a gente. É um desenvolvimento agêntico. É o futuro, galera. É o futuro e já é presente muito dessas coisas aqui. O que a gente não pode ter é uma fase de negação e acreditar que a gente vai programar da mesma forma e que o mundo vai ser igual e que a nossa profissão vai ser ficar movendo o cardzinho no gira e dando baixa nas nossas tarefas. Entendeu? O que eu tenho certeza é você precisa engolir IA. Você tem que aprender de verdade essa parada. Porque com a experiência que eu tenho hoje em dia, de ver outros desenvolvedores trabalhando com o IA, só estão arranhando a ponta do iceberg. Chega ali no cursor e fala, resolva aquele bug. Crie pra mim uma funcionalidade que fala, cara, meu amigo, isso não é trabalhar com o IA. Entendeu? Você só tá mudando o GPT pro cursor. E ele sai gerando um monte de coisa e você fica ansioso ainda. Quem aqui já passou ansiedade de cunhar, galera? Você pede pra fazer e daí ela começa a fazer no começo e você fala, cara, que top! Daqui a pouco ela começa a destruir de volta o seu código. E daí você começa com uma ansiedade porque você não sabe se você programa ou você pede pra ela arrumar e daí a coisa vai piorando, você começa a ficar nervoso e daí você sai sentindo mal e fala é uma merda entendeu? essa era a experiência que eu tinha com o Iá a minha experiência hoje em dia, ela é 100% feliz não é mas cara, eu digo que eu melhorei a minha eficiência pelo menos em 80% do que eu fazia antes, do que eu consigo fazer com o IA hoje, entendeu? Eu xingo muito menos, porque eu consegui ter um fluxo de trabalho decente. Existe um fluxo para software novo, existe um fluxo para software que já existe, existe fluxo para softwares que se comunicam, existem fluxos de trabalho pra cada tipo de situação, entendeu? Então, se você não sabe usar o prompt certo, o momento certo, se você não tem esses caras prontos, se você não sabe, se você não tem documentação, se você não sabe gerar documentação, se você não sabe criar um servidor MCP que vai ajudar a sua vida, se você não sabe os MCPs que podem ajudar a sua produtividade no dia a dia, você só vai ficar xingando a IA, até que um desenvolvedor que manja pra caramba vai conseguir fazer o que você não consegue e você vai falar, o que está acontecendo na minha vida? E daí você vai perceber que esse cara estudou mais sobre IA. E é o que eu recomendo pra todo mundo, galera profissão tá mudando vai ter vaga diminuindo vai ter vaga sendo redefinidas e o que está no nosso controle hoje? Estudar uma coisa é fato a gente tem que estudar parte técnica fundamentos, tudo isso que a gente tá falando estudar parte técnica, fundamentos, tudo isso que a gente está falando isso aqui, galera, tudo isso aqui que a gente está falando em todos esses dias, se você não souber isso, você pode usar IA que você for, vai sair uma merda. Se você souber isso aqui, e souber IA, a sua produtividade vai aumentar 10 vezes. Porque você não vai gastar tempo específico em código, porque código é commodity. Código agora tem menos valor. Porque deu ruim, faça um prompt bom, melhor. E galera, pensa que daqui a um ano, como é que vai estar o modelo? Daqui dois anos? Daqui três anos? Daqui cinco anos? A gente estava falando em janela de contexto, cara. Imagina, cara. O Gemini hoje tem janela de contexto de um milhão. Já está disponível para você usar no cursor. Um milhão de tokens para você já usar no cursor. Você já pode usar isso hoje. Entendeu? Então, é questão de tempo pra cada dia ficar melhor. O melhor dos mundos é você entender bem do que você precisa saber, você ser um bom arquiteto. Eu acho que as habilidades hoje em dia de engenharia de software de verdade, que inclui arquitetura de software, arquitetura de solução, entregas, as documentações, todas essas capacidades, realmente ser um engenheiro de software é o que vai fazer a diferença de você, junto com a IA, conseguir se destacar onde você está. Entendeu? o que vai fazer a diferença de você, junto com a IA, conseguir se destacar onde você está. Entendeu? Então, galera, profissão sendo redefinida, tem muita coisa ainda pra gente ver. E, obviamente, né, se você não quer ficar pra trás, também pegar muita coisa que a gente, aos poucos, está adicionando no MBA nosso, tá? A gente está adicionando no MBA nosso, tá? A gente está adicionando coisas de A também no MBA. Semana passada teve aula só sobre MCP, por exemplo. Então, a gente está adicionando aos poucos conteúdos de A que vão te ajudar pra caramba. Tem muita coisa já em gravação que eu vou disponibilizar. Vale muito a pena, galera. Aqui você vai encontrar vamos dizer ali, o melhor dos mundos então, dê uma chance pra você novamente, tire foto aqui desse QR Code ou clique no link, eu vou pedir pro link ir pra descrição novamente, preencha esse form, senta com a gente vamos fazer um bem bolado pra você entrar nessa turma, com desconto e caras tem muita coisa para você aprender. Eu acredito que a gente consegue te ajudar bastante. Se vocês acham que nesses dois dias vocês estão aprendendo bastante, imagina estar com a gente 18 meses. Faz sentido, né? Imagina por 18 meses a gente ter sessões no Zoom 18 meses você ter acesso a módulos 18 meses você tá ali com a gente e a gente sempre tá tentando manter conteúdo atualizado trazendo pessoas diferentes e trazendo talks fazendo sessões de mentoria então galera acredite que é um ótimo investimento para você. Clique no link e bate um papo aí com a gente. Pensou? Então, se em dois dias está sendo legal, bote isso em uma timeline de 18 meses. Tá? Essa é a provocação que eu quero fazer aí para vocês. Beleza? Pessoal, é isso para hoje. Espero que vocês tenham gostado do nosso bate-papo. Novamente, é teórico, mas novamente, é a teoria que se você não souber o zero, o um e o dois na hora de você configurar no Kafka, você pode gerar uma tragédia na empresa que você está trabalhando. E eu acho que são essas coisas que diferenciam um desenvolvedor que realmente é capaz de trabalhar em grandes empresas, de um desenvolvedor que saiba as coisas de forma superficial. Hoje vocês tiveram e viram uma série de possibilidades que a gente tem de trabalhar com diversos tipos de comunicação, protocolos e pegadinhas que a gente acaba tendo no dia a dia que acabam afetando muito a parte de resiliência entre sistemas. Maravilha, galera? Um outro ponto para vocês saberem, tá? E eu sempre vou tentar trazer isso com uma justiça para os nossos alunos, tá? As gravações dessas sessões que a gente está fazendo, elas não vão ficar disponíveis para vocês para sempre. Elas vão ficar disponíveis somente para quem é aluno, tá? Isso é uma forma, inclusive, de a gente fazer com que você venha e participe online. Acho que é justo para quem é aluno ter acesso. E para quem não é aluno, não está pagando nada, mas ao mesmo tempo está aqui participando com a gente. Então, espero que vocês entendam. A gente não vai disponibilizar essas gravações pra sempre aí pra vocês. Eu vou ver por quanto tempo, eu acho que até o final da semana a gente deixa disponível pra vocês poderem rever coisas desse tipo, mas isso aí depois vai ficar disponível apenas pra alunos, e se você vir aluno nosso MBA, você vai poder ver isso aí com mais calma, novamente, pra ter essa revisão aí com vocês. Maravilha, galera? Pessoal, preencham aí, formulário de pré-matrícula, sem compromisso, vamos entender seu momento profissional, espero que vocês possam também aí estudar com a gente, e esses encontros iniciais agora que a gente tá fazendo no Zoom acontecerem com muito mais frequência aí conforme vocês forem estudando com a gente. Fechou, galera? Pessoal, espero que eu não tenha desapontado, espero que vocês tenham gostado. Amanhã tem mais. Amanhã a gente vai falar de DevOps e SRE. Assunto que muita gente não sabe ou assuntos que muita gente confunde e não sabe a diferença entre DevOps e SRE eu conheço pessoas que trabalham na área de DevOps e falam que trabalham na área de SRE e esse cara não sabe o que é SRE mas fora isso a gente vai também falar de A aplicado a essa parte de confiabilidade de hiper confiabilidade em sistemas focados nessas partes de DevOps SRE, então vai ter mais assunto de A também pra gente falar amanhã tá bom? Então participem mesmo horário, vocês vão receber as notificações, links e tudo mais e espero que eu possa ver essas caras repetidas novamente aqui pra gente fechar com chave de ouro, fechou? Muito boa noite pessoal, fiquem com Deus descansem maravilhosamente que tenham um dia abençoado que vocês vão conseguir fazer tudo que vocês querem fazer e mais um pouco amanhã fechou? um abraço pra vocês e vamos nessa galera, porque amanhã tem mais, boa noite