Olá pessoal, eu me chamo Ronaldo Lanielas e nessa aula eu vou falar para vocês o que é o esquema REST. Bom, quando a gente fala de Kafka, existe a plataforma Kafka, como eu já falei nas aulas anteriores para vocês, e uma das ferramentas que tem nessa plataforma é o Schema REST. O que é o Schema REST? Ele vai te ajudar a você conseguir ter uma governança melhor dos seus dados. Então eu coloquei aqui, vou colocar o ponteiro. Então eu coloquei aqui os principais objetivos que você pode alcançar com o Schema REST, que é, primeiramente, a garantia de contrato entre produtor e consumidor. O que eu quero dizer com isso? Eu quero dizer que quando você tem uma mensagem que está sendo produzida, imagina uma mensagem em Hello World, e essa mensagem vai ser consumida de uma outra ponta, você pode, através do Schema Raster, definir um contrato forte para que essa mensagem ela seja sempre, aquele contrato seja obedecido. Então vamos imaginar aqui, por exemplo, que você precisa de três campos, idade, endereço e nome. E os três campos tem que ser string. Nesse caso você consegue conseguir uma hash de garantir que esses três campos vão ser sempre obedecidos, vão ser sempre obedecidos, vão ser sempre preenchidos, etc. Esse é o principal objetivo, quando a gente fala de esquema resta. Um outro objetivo é a evolução desse contrato. Então, por exemplo, hoje você tem esse esquema com três campos, idade, nome e endereço, e amanhã pode ser que você precise adicionar um novo campo, o que é muito comum. Quando você adiciona esse novo campo, você tem que manter, ou não, dependendo do que você queira, a compatibilidade com o esquema anterior. Por que isso? Para você não quebrar, imagine que você é um produtor que tem 50 consumers e você está evoluindo esse esquema adicionando um campo novo. Você, obviamente, não quer quebrar todos os consumidores que estão consumindo a sua mensagem. Então, você precisa, de alguma forma, garantir a retrocompatibilidade entre esquemas. E aí o SchemaHack também garante isso para você. A gente vai falar na próxima aula como ele garante isso, mas por agora é importante você entender que é possível essa garantia. E como eu falei, a governança de dados é o que você ative com o Schema REST. Então, tanto garantir a retrocompatibilidade como o contrato entre produtor e consumidor é governança de dados. Mas, além disso, você pode, por exemplo, criar pipelines, etc., na sua empresa para garantir que aquele esquema não vai subir com uma informação PII, por exemplo. Então, você não pode colocar um CPF em uma mensagem porque é uma informação PII, por exemplo. Então, você não pode colocar um CPF em uma mensagem porque é uma informação PII para esse sistema específico. Então, nesse caso, você pode criar um tipo de governança em cima da criação de esquemas. E aí você meio que nega a criação de esquemas que têm informação PII. Esse é um exemplo, mas o que eu quero dizer aqui é que a governança pode aplicar a governança de dados em cima desses esquemas. Aqui é um exemplo de como funciona um esquema REST em uma arquitetura com Kafka. Então você tem aqui um cluster de esquema REST, que é um cluster totalmente separado do cluster de Kafka. Ele usa o cluster de Kafka, mas ele é uma aplicação separada. Você tem aqui o Schema Creator, que nada mais é do que o cara que está criando o Schema. Então, pode ser a sua aplicação, pode ser você mesmo fazendo essa criação manual do Schema. Vai falar um pouco sobre como criar o Schema e fazer isso na prática, nas próximas aulas mas aqui o Schema Creator é aquele produtor geralmente que está tomando conta do contrato e aí ele vai chamar esse cluster de Schema e vai falar, cria para mim esse Schema aqui com três campos idade, endereço e nome e aí, dado que esse Schema está criado, ele vai ter um ID, vamos imaginar ID 1. Quando um microserviço for produzir uma mensagem, seja ele qualquer linguagem, Java, .NET, Golang, Python, etc. Ele vai fazer o quê? Primeira coisa, ele vai bater no esquema REST, e ele vai pegar esse esquema que foi criado. Então, esse esquema de ID 1, ele vai pegar esse esquema que foi criado. Então esse esquema de 1 ele vai carregar em memória essa definição de esquema, vai usar esse esquema para serializar a mensagem. Então na verdade não vai usar o esquema, deixa eu só corrigir, verdade, ele vai pegar o esquema, vai serializar a mensagem no formato que você quer e vai colocar o esquema junto da mensagem serializada. Então, não é que ele usa o esquema para serializar a mensagem, mas o esquema vai junto da mensagem serializada. E aí pode ser em formato, que eu vou falar daqui a pouco. Então, você tem a mensagem serializada com esquema e ela é produzida no Kafka. Na outra ponta a gente tem o consumidor. O consumidor vai fazer o que? Ele vai ler a mensagem, ele vai fazer o deserializer da mensagem. Então ele vai ler a mensagem deserializada com esquema. E aí vai fazer o que? Vai validar se aquele esquema está ok ou não. Percebe que aqui tanto o produtor como o consumidor fazem um getSchema. Então eles vão lá no Schema REST, pegam o Schema e carregam em memória. Isso só uma vez. Ou quando o Schema tiver alguma alteração. Mas ele não fica batendo toda hora, então se você tem muita volumetria não se preocupe, porque se você tiver 1000 TPS, 1000 transições por segundo, ele não vai bater 1000 TPS no esquema REST. Ele bate geralmente uma vez só, carrega em memória e usa aquele esquema. É importante dizer que todo tipo de validação de esquema é feita diretamente no Schema REST. E de novo, em memória, etc. Não fica batendo toda hora no Schema REST. Aqui são alguns formatos suportáveis do Schema REST. Hoje é suportado Avro, ProtoBuf e JSON Schema. Eu coloquei aqui um exemplo de Avro. Então, para cada tipo de formato, você tem uma formatação diferenciada, obviamente. Mas aqui é um formato que eu pessoalmente gosto bastante, que é o Avro, que é o ProtoBuf. Então, o ProtoBuf aqui, você tem uma mensagem, o nome da mensagem, o nome daquele... vamos dizer como se fosse uma classe. Se a gente fizer uma comparação com Java, teria o search request como se fosse uma classe lá no Java. Mas aqui é protobuf. E aqui você tem os campos com a ordem dele. Então, esse é o primeiro, esse é o segundo, esse é o terceiro, o nome do campo e o tipo do campo. Beleza? E aí, se você tiver mais dúvida, se você digitar no Google protobuf definition, você vai encontrar todos os tipos possíveis que você pode usar. Por exemplo, se você tem uma lista, você pode usar repeatable, etc. Não vou entrar em detalhes aqui. Não é o objetivo mostrar detalhes do protobuf, até porque você pode escolher Avro ou JSON Schema, isso depende do que você precisa. E para fechar aqui, eu queria só deixar claro que o schema REST, ele tem dois principais cores, dois principais grandes funcionalidades, vamos dizer assim. A primeira é o REST API. Todo tipo de comunicação com o sistema REST é via REST API. Então, quando você cria um esquema, quando você vai validar um esquema, quando você vai evoluir um esquema, você faz isso sempre via REST API. Inclusive, quando o produtor e o consumidor precisam pegar aquele esquema, eles fazem isso também via REST API. E outra coisa é os SEGS, que são os serializers e deserializers. Então, o que acontece é, o seu cliente, a sua aplicação, quando a gente fala client, a sua aplicação client, ela precisa ter um serializer ou deserializer, dependendo do que ela vai fazer. Se ela for um produtor, ela vai ter um serializer. Se ela for um consumidor, ela vai ter um deserializer. E se for uma aplicação que produz e consome, vai ter os dois. Existem N plugins, vários plugins para diversas linguagens, que fazem serializer e deserializer desses formatos aqui, tá? Então, a gente vai ver em Go, no hands-on, nas próximas aulas. E você vai ver que a gente tem serializer e deserializer nibs em Go específicas para você fazer serializer em protobuf, por exemplo. E deserializer em protobuf, assim como o A de serialize em protobuf, assim como a árvore de Jusquima. Ok? Espero que vocês tenham gostado e até a próxima.