Agora que a gente entendeu um pouco melhor sobre comunicação síncrona e assíncrona, a gente tem que começar a pensar que a gente tem várias formas de se comunicar nessas duas categorias. A gente tem a possibilidade e às vezes a gente só acaba utilizando uma. Então, eu vou colocar aqui como protocolos, de forma geral. O que normalmente a gente fala quando a gente vai trabalhar com uma comunicação síncrona? O que é mais antigo do que andar para frente quando a gente está trabalhando hoje em dia? A gente está falando em REST, em HTTP. É o que 99% dos sistemas, de forma geral, que são populares, a gente sabe que a gente acaba expondo APIs via HTTP, trabalhando ali com REST, de forma geral. O grande ponto é que o REST, dependendo da situação, ele pode ser uma grande vantagem, porque é um protocolo e é uma forma de comunicação muito comum. É fácil de você debugar, de você olhar um JSON, de você entender como as coisas funcionam. A gente tem ali o OpenAPI, que vai conseguir nos ajudar para bastante coisa, as documentações, ou seja, isso é amplamente utilizado na internet. Então, a gente tem uma tentação muito grande de sempre disponibilizar uma conexão HTTP, principalmente quando a gente está falando de client-server, inclusive o usuário final, eu estou acessando aquele sistema, o meu front-end está batendo naquela minha aplicação. Isso aí é super, ultra aceitável, muito recomendado em muitos momentos. Mas a gente tem que pensar que não é só o REST que existe e que em muitas situações o REST acaba sendo até mais inadequado, tá? Mesmo para comunicação síncrona. Por quê? Porque o REST, de forma geral, ele trabalha sobre o protocolo HTTP e normalmente como a gente está enviando informações apenas com JSON e etc., ele não utiliza ali as grandes vantagens do HTTP2, ok? E a gente está falando em JSON. JSON tem uma vantagem muito grande. A gente olha, a gente entende. É fácil de debugar. Você coloca em qualquer VS Code, você coloca em qualquer lugar, você consegue olhar, você consegue criar suas requisições, de tudo quanto é forma. Então, isso é uma tentação muito grande, porque é fácil, é simples, todo mundo usa e a gente fica ali sempre confortável em trabalhar. Mas, quando a gente está falando em sistemas muito grandes, grande parte da comunicação desses sistemas não acontece do usuário do front-end pra bater primeiramente num back-end. Acontece por trás dos panos. Essa que é a grande questão. A gente tem no mundo hoje de computação distribuída, que são ali milhares e milhares, sei lá, Mercado Livre tem 30 mil microserviços, Uber tem ali também um trocentos. Agora, imagina o seguinte, se todos os microserviços que esses caras se comunicam, mesmo de forma assíncrona, fossem utilizar apenas HTTP para se comunicar. O que isso ia acontecer no final das contas? Ia conseguir se comunicar? Ia. Agora, qual que é a performance disso? Né? Essa aí é uma questão que não quer calar. Existem empresas que não utilizam necessariamente HTTP pra fazer comunicação ali entre os seus backends. Porque existem outros protocolos que dependendo do contexto, eles são mais recomendados. Eu vou falar um muito claro aqui pra você, que é o famoso GRPC, tá? O GRPC, só pra você ter uma ideia, virou uma forma padrão de comunicação em grandes empresas pra parte de backend. Foi criado no Google, o Google por trás dos panos, basicamente tudo que é de comunicação que eles trabalham, eles usam massivamente gRPC, mas a questão não é só Google, tá, se você olhar hoje em dia até sistemas de observabilidade você pegar Open Telemetry grande parte de como que as informações de telemetria são passadas são via gRPC, então é claro aqui nesse caso que o gRPC ele é uma forma super adequada de você conseguir trafegar dados de uma forma muito mais rápida, usando muito menos banda, gastando menos recurso computacional. Então, nesse caso, nem sempre o HTTP vai ser o melhor protocolo. Deixa eu até melhorar, porque o gRPC o melhor protocolo. Deixa eu até melhorar, né? Porque o gRPC usa o protocolo HTTP2, né? Mas o payload que ele é passado, ele é passado via binário utilizando protocol buffers que a gente vai falar daqui a pouco, tá? Grande sacada também do gRPC aqui é que ele consegue trabalhar de forma, no formato de streams. Então, o que acontece? Eu consigo fazer de forma, inclusive, bidirecional, com que conforme eu vou mandando os dados para você, você já vai conseguindo ler esses dados, e às vezes, conforme você vai recebendo esses dados, você já consegue ir me retornando esses dados sem todo o processamento ter acabado de acontecer. Ou seja, eu consigo otimizar muito a parte de comunicação. Além do buffer, além do payload ser um binário que acaba sendo muito menor do que um JSON, o tempo de serialização desse JSON, do JSON é muito maior do que você serial, o tempo de serialização desse JSON, do JSON, é muito maior do que você serializar um binário. Tudo que é human readable, basicamente como um JSON, que normalmente é texto, a gente sempre vai usar muito mais CPU pra gente conseguir fazer essa serialização. No caso, quando você trabalha com protocol buffers, a gente tá falando de um binário, é muito mais rápido você fazer a serialização de um binário para um objeto do que de um texto fazer um uso intensivo de CPU para colocar, nossa Wesley, mas isso é detalhe, não é pega um sistema que tem muita concorrência que tem muito acesso isso faz uma diferença muito grande na velocidade, na latência e no bolso da empresa com a economia de recurso computacional. Então, isso que eu tô falando aqui não é questão de nem ser utopia, é só em que eles... Cara, isso já é realidade e ponto, tá? Pra gente é mais cômodo ficar a vida inteira ali com REST, mas acredite, existem outros formatos de trabalho muito interessantes que não são difíceis de utilizar, inclusive o gRPC é muito maduro, tem para tudo quanto é linguagem e é bem simples de utilizar de forma geral. O nível de dificuldade de trabalhar com gRPC, pelo menos para quem está acostumado, é algo muito tranquilo. Tem outro cara aqui, de forma assíncrona, que cada dia a gente vê menos pessoas falando, né, que é o GraphQL. A grande sacada desse cara é você conseguir ter muito mais flexibilidade para receber dados e para enviar dados, né? O seu front-end, quem consome, consegue escolher como os dados eles vão ser trazidos e isso aí muda muito o jogo. Mas, honestamente, galera, apesar da ideia ser muito boa, tem, obviamente, empresas que ainda utilizam e tudo mais, eu vejo que esse cara aqui, ele não tem um uso, uma aderência, uma adesão tão grande. Eu lembro que quando lançou, eu pensei que isso ia mudar o jogo, e que, que inclusive REST ia até ter uma boa queda nessa utilização. Muita gente nessa época cogitou que o GraphQL ia ser a forma padrão de comunicação exatamente por conta de todas essas facilidades, mas isso foi coisa que não aconteceu e cada dia mais eu vejo isso caindo em desuso, tá? Próximo vídeo a gente ainda vai falar sobre outros caras, mas a gente vai começar a entrar um pouco na parte de assincronismo e depois a gente também vai falar um pouco sobre os payloads, né? No caso, o protocol buffer, a gente vai falar sobre um cara que é o flat buffers, a gente vai falar sobre o JSON e etc. Vamos seguindo aí nos próximos vídeos.