Oi pessoal, boa noite. Eu me chamo Ronaldo Lanheiras e nessa aula a gente vai ver na prática como utilizar o esquema RESTRE em Golang. Então vamos começar aqui. Eu criei um main.go bem simples que vai fazer uma produção e um consumo usando o esquema RESTRE. Mas antes de começar eu queria mostrar para vocês aqui o nosso Docker Compose. Deixa eu fechar tudo aqui. O nosso Docker Compose é baseado nas outras aulas, ele se repete, então ele tem o Zookeeper, ele tem o Broker, tem o AKGQ, mas o que a gente adicionou de novo aqui foi esse esquema. mas o que a gente adicionou de novo aqui foi esse esquema então ele é o esquema RESTRE, uma imagem do esquema RESTRE da Confluent, a porta dele é na 8.81 ele depende do broker para ficar de pé e aí no Akai.q eu adicionei também esse atributo a mais, o que é isso? na hora que você for ler mensagem agora, você precisa de um schema hash para deserializar a mensagem. Se você não colocar essa informação, na hora que você abrir a mensagem no KHQ, ela não vai ficar legível. Então você precisa dizer para o KHQ onde está o schema hash para que você consiga deserializar a mensagem. Aqui eu? Bom, aqui eu vou botar para rodar. No meu caso já está rodando. Vou só dar um up-d de novo. Então está aqui. Aqui, o Zookipper, o Broker, o HHQ e o Schema. Eu já mandei uma mensagem. E aí eu quero mostrar para vocês aqui qual é a diferença quando a gente tem Schema Raster. Então eu criei um tópico aqui chamado client. Se eu abrir esse tópico, o que você vai perceber de diferente? Bom, se você olhar só a mensagem, a mensagem é um JSON igual como qualquer outro. Só que quem percebeu aqui, a gente tem um ato muito novo que é o schema. Se você clicar nesse value aqui, ele vai te direcionar exatamente para o seu schema. No nosso caso a gente definiu em Avro. Vou já mostrar para vocês como é que a gente criou esse schema. Mas olha só, ele criou um schema em Avro, com os campos, definição do campo, valores de default, etc. E esse meu esquema tem duas versões. Tem a versão 1 e a versão 2. Se a gente comparar aqui, a versão 1 não tem cidade. E a versão 2 tem a cidade. Que foi adicionada na versão 2 desse esquema aqui. Bom, isso só é possível, de novo, só é possível você ver todas as informações aqui nessa engrenagem, porque a gente colocou essa configuração de esquema Rectal aqui no AKHQ. Então, independente de quantos esquemas REST, desculpa, de quantos Subjects você tiver, vai aparecer aqui. Aí eu queria falar um pouco sobre Subject para vocês. Eu falei um pouco na aula passada, teoricamente, mas assim, o subject nada mais é do que a junção do nome do tópico, um traço e um value. Se você estiver fazendo esquema do value. Se for uma chave, se você tiver fazendo esquema da chave, então é nome do tópico, traço, key. Porque você pode tanto aplicar o esquema schema deixa eu abrir aqui de novo na chave, que no nosso caso é nula, não tem chave ou no VELO no nosso caso a gente só está aplicando no VELO para simplificar aqui entenda que o Subject é a junção de tópico e VALUE ou KEY mas existem configurações onde você pode mudar isso, você pode colocar valores diferentes aí no meio para criar os seus objetos. Mas para simplificar aqui, na maioria dos casos você vai ver utilizando o nome do tópico e value ou key. Aqui eu tenho o tipo de esquema e aqui a quantidade de versões que ele tem. Aqui na verdade é a última versão. a quantidade de versões que ele tem. Aqui na verdade é a última versão. Então vamos começar a dar uma olhada no código agora. O que é interessante aqui no Schema Raster? Primeiro, para produzir, de novo, em diversas aulas eu já mostrei como produzir Golang, então não vou perder muito tempo nessa parte, mas você vai criar um produtor normal, como você já fazia antes. O que tem de novo aqui? Você precisa criar um client usando esse pacote Schema Raster e esse client vai te pedir a URL do Schema que eu já defini bem aqui, 831 lembra? que a gente definiu lá no Docker Compose. Quando eu crio esse client, eu preciso criar um serializer. Esse serializer vai ser o carinha responsável por pegar minha mensagem e serializar no formato que eu quero, nesse caso é algo. Então eu passo esse meu client aqui para esse meu serializer e digo que ele é um value. Por quê? Se você clicar aqui, você vai ver que ele tem dois tipos, o Key ou o Value. Lembra que eu falei, né? Se você estiver fazendo uma serialização de Value, você vai usar ValueSerd. Se você estiver fazendo uma serialização de Key, vai ser KeySerd, tá? E aí, baseado nisso, ele vai ter aquele Subject, né? Então, se for um ValueSerd, vai ser o nome do tópico, que no meu caso é client, value, se for um key-serd vai ser o nome do tópico, traço key, é assim que funciona. Depois que eu crescer a liza, eu de fato vou serializar minha mensagem. Então eu vou pegar aquela minha struct que está definida aqui em cima. Beleza. E vou colocar os valores e serializar ela. E ele vai se transformar em um byte array. Porque lembra, voltando para o canal passado, o Kafka não entende qualquer outro tipo de dado que não seja byte array. Apesar de você passar para ele Avro, JSON, XML, no final você está serializando aquela mensagem em byte array. E aí, do outro lado, ele vai deserializar e transformar para o formato que ele quer. Então, o producer serializa e manda em byte array, o consumer vai deserializar para o formato que ele quer, ou seja, vai transformar ele em byte array para um formato que pode ser um struct e etc. Nessa etapa, quando a gente faz o serializer internamente, acontece algumas coisas aqui que uma delas é bem interessante que é a criação do subject. Normalmente você faria isso de forma manual. Normalmente não. Geralmente a gente faz de forma automática mesmo que é via código. Mas se você é um cara que quer fazer de forma manual, você poderia usar as APIs do Schema Rectif, por exemplo. Vou até mandar aqui um request do Postman. Então se você olhar aqui, eu estou batendo no 831, subjec, então ele vai me listar todos os Subjects que eu tenho. Assim como eu posso criar também, eu tenho um endpoint onde eu posso criar o Subject do jeito que eu quero. Bom, a gente não vai usar criação via API, você poderia se você quiser, definir seu árvore manualmente, colocar o Scheme, etc. Eu gosto mais de fazer da forma automática que funciona da seguinte forma. O produtor, nesse nosso projeto, é o responsável por criar a definição do schema. Então eu deixo que ele crie o schema e ele vai ser o owner desse schema. Ele vai adicionar campo, remover campo, etc. Que é o que geralmente faz muito sentido. É claro, tem casos onde o consumo era o owner. Mas aqui vamos pensar que o produtor é o owner. Tem casos onde o consumo era o álbum. Mas aqui vamos pensar que o produtor é o álbum. E aí ele vai produzir uma mensagem com esse nome, o país e a cidade. O consumidor, por sua vez, o que ele vai fazer? Ele precisa pegar essa mensagem e consumir usando esquema. Imagina, aqui para facilitar eu coloquei na mesma aplicação, mas no mundo real, o consumidor e o produtor são aplicações diferentes. Aqui vem a primeira vantagem de você usar esquema Raster. Se você vir aqui no AKHQ, de novo, você tem aqui a definição Avro, que foi gerada automaticamente quando você produz a mensagem. Então, a primeira mensagem que você produzir vai ser gerada automaticamente quando você produz a mensagem. Então, a primeira mensagem que você produzir vai ser gerada esse Avro aqui automaticamente para você. Você pode copiar ele, colocar aqui no arquivo Avro, AVSC, né? Então, coloquei aqui. Imagina que agora eu sou o consumidor, tá? Não sou mais o produtor. Então, em algum momento, o produtor falou, oi, consumidor, está aqui o produtor. Então, em algum momento o produtor falou, o consumidor está aqui o arquivo abre, você tem que conseguir mensagem seguindo esse formato. Bom, o que o consumidor vai fazer? Ele vai gerar as struts dele em Golang baseado nesse arquivo. E aí tem duas formas de fazer isso, manual ou de forma automática. Obviamente, a gente vai fazer de forma automática aqui. Existe uma ferramenta chamada Avro Go, onde você coloca qual é o diretório que ele vai gerar esses structs para você, qual é o nome do pacote que ele vai gerar, e qual é o nome do arquote que ele vai gerar e qual o nome do arquivo que ele vai ler. Nesse caso eu abro para gerar esses structs. Se eu dar um enter aqui, ele vai gerar aqui dentro do alt. E olha o que ele fez aqui para mim. Ele gerou struct, gerou mais algumas funções aqui que eu precisar usar, etc. Mas o mais importante é que aqui é uma extract muito simples, né? Mas poderia ser uma extract alinhada com vários campos, etc. E o consumer não precisa se preocupar em implementar tudo isso. Ele vai pegar o arquivo Avro e vai gerar essas extracts, tá? Beleza. E aí fica muito legal porque se eu precisar, por exemplo, atualizar o meu Avro, eu vou simplesmente mandar atualização para o meu consumer e ele vai regerar o struct e está tudo certo. Não corre o risco de colocar o nome errado ou algo do tipo. É muito parecido com o que a gente já trabalhou com o SOAP, por exemplo, XML é muito parecido você tem lá o seu WSDL e gera os seus arquivos a partir do WSDL aqui é muito parecido bom, se eu olhar para o consumer agora de novo eu crio o consumer nada novo e aí eu defino o meu client de schema hash, igual como eu fiz no producer, nada novo também. Aqui muda um pouco, em vez de usar um serialize eu vou usar um deserialize, obviamente, porque eu vou deserializar. Aqui não muda nada, eu vou me inscrever naquele tópico, é o mesmo tópico do producer. Aqui a mesma coisa que a gente já tem falado nas últimas aulas, então eu criei um signal para poder cancelar esse consumo quando eu quiser com ctrl c etc. E aqui, se vocês olharem, quando eu vou deserializar a mensagem, eu chamo esse método de deteralizeInto, passando o tópico, o value, esse value aqui é um byte array. Lembra que eu falei que o Kafka vai me dar um byte array e eu preciso converter esse cara para uma struct nesse meu caso. E essa struct aqui está dentro daquele arquivo que foi gerado pelo Avro Go. Você pode me atrapalhar, mas você poderia simplesmente definir aqui usar esse client que já está criado aqui. Mas lembra que aqui é um exemplo. No caso real você não vai ter o mesmo struct porque não vai ter projetos iguais o consumer vai estar rodando um projeto totalmente separado do producer geralmente, e as vezes os times nem se comunicam então, o time que está consumindo nem conhece o time que está produzindo e está tudo bem só precisa o time que está produzindo de alguma forma expor esse arquivo e qualquer outro time consegue consumir seguindo aquele formato. Bom, aqui eu vou dar um go run, eu vou primeiro produzir uma mensagem então só para vocês verem que está funcionando, eu vou comentar isso aqui, vou voltar aqui, eu estou com 10 mensagens eu vou produzir uma mensagem. Demorando um pouco. Pronto. Então está aqui. Foi produzida. Posso abrir aqui só para vocês olharem que realmente foi uma mensagem produzida aqui. Nome, cidade e país. E aí se eu voltar aqui, agora eu vou consumir. Então eu vou comentar meu produto, vou mandar consumir. O meu lag, ele é de uma mensagem, então está aqui a mensagem que eu acabei de produzir. É essa aqui, perfeito. Então, funcionou do jeito que a gente queria. Bom, acho que até para vocês perceberem a vantagem do Avro, além de você conseguir principalmente compartilhar o contrato de um produtor para vários consumidores, ou vice-versa, se você tiver o consumer como o Alder, você consegue pegar o contrato e também publicar para vários produtores. A propósito, as empresas que eu trabalhei, inclusive, a gente tinha um portal de arquivos Álvaro, então quem precisava consumir um contrato específico ia lá e pegava aquele contrato, colocava na aplicação, era bem produtivo e governado. Então, essa é uma das vantagens muito boas quando você usa Schema Red. Espero que vocês tenham gostado, pessoal, e até a próxima.