e agora pessoal a gente tem que falar de protocolo em si mas quando a gente está falando vamos dizer assim de payload em si e aqui eu quero discutir deixa eu colocar aqui protocolos payload aqui nesse caso e aqui eu quero discutir um cara que novamente poucas pessoas acabam conhecendo e normalmente ele é utilizado junto ao gRPC, mas ele não precisa ser utilizado necessariamente junto com o gRPC, que é o famoso protocol buffers, tá? Ou o proto buff. Legal? O protocol buffers,ers foi criado na Google e basicamente você define o esquema desse cara num arquivo .proto. Ou seja, esse tipo de arquivo ele meio que vai definir como que é o estilo do dado que você vai trafegar. E o que acontece no meio dessa história? Quando o seu sistema vai trabalhar com protocol buffer, ele lê esse esquema, nesse arquivo .proto, e ele pega baseado nesse esquema e serializa esse dado num formato binário. Ok? E daí quando você vai mandar essa informação de um sistema para o outro, esse binário é muito menor do que um JSON, a serialização é muito mais rápida, né? E a transferência de dados acaba sendo menos custosa. Você gasta menos bandwidth, você consegue mandar os dados com uma latência menor e você usa menos poder computacional para a parte de serialização. Então, quando a gente está falando em performance aqui de forma geral, quando você está trabalhando com protocol buffers, é uma solução muito, mas muito mais rápida do que você trafegar dados como um JSON. Tem desvantagem? Você não vai conseguir abrir um arquivo binário no seu VS Code e ver o que tem dentro. Então você, nas suas ferramentas, na forma como você trabalha, você tem um jeito ali um pouco mais específico de debugar. É mais difícil de debugar? Na prática, eu não acredito que seja tão mais difícil. É que no JSON a gente faz muita coisa no olhômetro, no protocol que seja tão mais difícil. É que no JSON a gente faz muita coisa no olhômetro, né? No protocol buffers, não. Você faz isso baseado num objeto, que daí ele gera um arquivo. É basicamente isso que acontece. Mas é muito mais rápido e normalmente é utilizado em conjunto com o gRPC, tá? Então, o gRPC, ele transporta os dados via HTTP2, que é bem mais rápido do que a HTTP1, mas o payload ainda que é enviado, ele é um arquivo binário, e daí a coisa fica cada vez muito mais rápida. A grande sacada aqui é que esse esquema, ele pode ser evolutivo. Então, eu consigo ir mudando ao longo do tempo esse esquema aqui, sem gerar um prejuízo muito grande, porque eventualmente a gente quer mudar o formato do dado, o tipo da informação, então tem diversas estratégias que você consegue trabalhar nesse arquivo ponto-pronto. É legal, o que eu gosto bastante dessas abordagens, é que às vezes quando a gente está trabalhando com o JSON, a gente, ah, vou mandar e daí você manda um inteiro com uma string e coisas desse tipo e r gente, ah, vou mandar, e daí você manda um inteiro com uma string e coisas desse tipo, e raramente a gente tem um contrato muito forte, né? Quando você tá trabalhando com esses protocolos, não tem muito o que fazer. Você tem que seguir exatamente o que tá definido naquele contrato. É bom porque todo mundo tá falando sempre da mesma forma. Você vai ter menos problema com quem envia e com quem recebe, como muitas vezes acontecem com o formato JSON. Mas, novamente, não é algo que você bate no olho. Se você precisa fazer comunicação interna entre sistemas, principalmente internas, onde não vai ter usuário final ali, usuário mexendo ali nessas comunicações, um sistema manda uma solicitação pra processar um relatório, que manda o relatório pra um lado e que faz um processamento pro outro. Cara, trabalhar com protocol buffers nesse tipo de coisa vale muito, muito menos a pena, tá? Então, né, tem uma curvinha aí de aprendizagem pra você conseguir aprender a trabalhar com ele, mas aquela história, às vezes a gente acha que é difícil porque a gente tá acostumado já com HTTP e JSON e REST e etc. Talvez se você tivesse começado na sua carreira já com protocol buffers, eventualmente você ia achar o REST às vezes até mais complicado. Então a gente tem que tomar um pouco de cuidado com esses tipos de coisa, tá? E aqui por último, eu quero trazer uma outra opção que ela não é tão popular, mas ela é muito eficiente e ela é muito rápida, mas tem coisas, mas normalmente são usados para cases mais específicos. Um desses caras aqui é chamado de Flat Buffers, tá? O que é um Flat Buffer no final das contas? O Flat Buffer é uma forma de você conseguir também trafegar dados binários, tá? Também foi feito lá na Google, tá? Mas a diferença é que não há serialização na... Não há deserialização, deserialização deserialização na leitura o que que isso significa? toda vez que eu mando um JSON o meu programa que vai ler e vai dar um pra pegar o nosso JSON e transformar ele num objeto, a gente usa CPU porque a gente tá deserializando a gente tá pegando um texto e convertendo esse cara em objeto. E isso gasta CPU. Quando eu estou trabalhando com protocol buffer, mesma coisa, apesar de ser um arquivo binário e a deserialização ser mais rápida, ainda assim há deserialização. Por quê? Porque eu estou pegando um dado, carregando esse dado na memória e deserializando. O JSON, mesma coisa. Eu pego o JSON inteiro, se for gigante, carrego na minha memória, ou seja, ocupo a minha memória e daí deserializo. O FlatBuffers é diferente. Por quê? Ele manda um buffer de dado e dentro desse buffer ele tem o quê? Ali no final das contas, ele tem offsets e os dados. Então o que isso significa? Significa que quem vai ler esse cara, não precisa carregar tudo na memória de uma vez e disserializar. O que ele faz é, eu recebo essa informação, eu coloco o buffer na biblioteca que eu vou trabalhar e eu falo, eu quero pegar o nome. Aí ele sabe, opa, o nome está na posição 20. Então eu sei que da 20 até ali é uma string, então eu retorno aquilo. Ou seja, eu não precisei carregar os dados na memória. Eu simplesmente fui naquele local onde aquele buffer está me apontando e lendo só aquele pedaço que eu preciso. Ou seja, não existe deserialização. Eu vou, pego o dado on demand dentro de um buffer. Isso é muito bom por quê? Porque muitas vezes a gente quer ler um campo e a gente recebeu 10 campos. Mesmo que seja com protocol buffer, você vai ter que carregar o objeto inteiro na memória, deserializar, gerar seu objeto pra conseguir pegar apenas um campo. No caso do flat buffers, tá tudo lá, mas se eu quero aquele campo, eu vou direto naquele offset, pego só aquele dado daquele campo e não precisei carregar o resto na minha memória. Ou seja, é binário, é super leve, eu não preciso deserializar e eu tenho acesso ao buffer da informação diretamente sem precisar fazer essa deserialização, todo esse processo que a gente acaba trabalhando. Normalmente, a extensão do esquema desse cara é chamado de FBS. todo esse processo que a gente acaba trabalhando, tá? Normalmente, a extensão, né, do esquema desse cara é chamado de FBS. Agora, por que que esse cara não é tão conhecido, ele não é tão utilizado no dia a dia como muita gente acaba falando? E na realidade não é tão utilizado quanto o Protocol Buffer também. Mas por quê? Esse cara, ele acaba sendo, de forma geral, um pouco mais complexo, já que o protocol buffer, que é binário, a gente lê o arquivo inteiro de serializa, acaba sendo um pouquinho mais chato do que o Leon Jason, o flat buffers acaba sendo, entre aspas, um pouquinho ainda pior. Não estou dizendo que é difícil, eu já trabalhei com flat buffers, não acho difícil, mas ele tem uma peculiaridade, ele é um pouquinho mais chatinho, porque você tem que ter uma hierarquia, uma árvore conforme você vai achando esses offsets. Não é difícil, tem um monte de biblioteca pronta pra isso, mas é o que é. Agora, normalmente isso é muito recomendado quando você precisa fazer uma comunicação com um tempo real muito grande, né? Ou seja, a sua latência tem que ser mínima, né? Tem que usar pouco recurso computacional pra você trabalhar. E aonde que muita gente acaba utilizando aí o Flat Buffers? Games, galera. Hoje em dia, né? Sabe, pessoas têm que mandar mensagem, têm que contabilizar ponto, têm que conseguir pegar informação daquele cara, do outro, e tem toda essa comunicação interna pros games funcionarem e tudo isso, cara, normalmente o Flat Buffers é muito utilizado pra esse tipo de coisa, tá? Então, a grande sacada é, ele trabalha com buffers, você acessa esse cara diretamente, sem precisar ler inteiro, e quando você precisa realmente baixíssima latência, né? Engine de jogo, cara, é um exemplo assim muito clássico, tá? Para você conseguir trabalhar. Então, se você quer fazer processamento de dado, de estado, de como está tal situação naquele momento, você lê aquele buffer, pega só aquela informação que você precisa e acaba carregando. Então, aqui a gente tem algumas formas de a gente trabalhar com maneiras de comunicação síncrona, assíncrona, com todas as variedades que a gente pode ter. Tem outros protocolos, tem outras formas de trabalhar e etc., com certeza. Mas nos dias de hoje, isso que eu acabei de passar é o mínimo que você precisa saber, pelo menos que existe, para você conseguir sentar em qualquer mesa e começar a discutir possibilidade de comunicação entre sistemas. Então, eu acho que esse aí é o grande ponto.