Olá pessoal, boa noite. Eu me chamo Ronaldo Lanias e hoje eu vou mostrar para vocês como que funciona o ciclo de vida de um esquema. O que eu quero dizer com ciclo de vida? Quando você está criando e manipulando um esquema, você tem que evoluir ele de alguma forma. E quando eu falo evoluir, não é só criar campo, mas também deletar campos, etc. Qualquer tipo de alteração que você faz no esquema, você está evoluindo ele. E aí a gente precisa entender como é que é o ciclo de vida, como é que isso funciona, retrocompatibilidade, etc. Então, como eu falei, qualquer alteração que você faz no esquema, você está evoluindo ele. Seja para, de alguma forma, deletar um campo ou criar, adicionar um campo opcional, mudar o tipo de um campo, você está evoluindo. E aqui a gente precisa garantir e ter uma certa compatibilidade entre produtor, consumidor e versões anteriores. E, de novo, de nada adianta você ter o esquema se você não tem um tipo de controle entre as versões. Quando você cria uma nova versão, você vai quebrar todos os consumidores e produtores, então não faz sentido. Então assim a gente garante, ou não, vou já falar o porquê se ou não, a retrocompatibilidade entre esquemas. Então é um ponto aqui bastante importante. O que tipo de compatibilidades existem? São esses aqui, esses set, backward, backward transitive, forward Forward, Forward Transit, Pull, Pull Transit e o None. Vou explicar cada um desses para vocês e vai ficar muito mais simples em forma de tabela. Eu primeiro vou passar aqui na tabela, depois eu vou abrir o Sc Calidrol e faço um exemplo mais prático aqui para vocês, que eu sei que, acho que no primeiro a olhar pode parecer um pouco complexo como é que funciona a compatibilidade entre esquemas, mas não é tão complexo assim, tá? Da forma que você entende um ou dois, na hora que você entender três aqui, você entende o resto, você vai entender porquê. Então, assim, o backward, quando você cria um esquema, a gente vai ver isso na prática, né? Quando você cria um esquema, você indica qual é o tipo de compatibilidade dele. E aí, o padrão, se você não colocar nada, é backward. E aqui, se você colocar especificamente, ou não colocar, enfim, esse é o padrão, o que é permitido é que você delete campos e adicione campos opcionais. Ponto. O que eu quero dizer com isso? Ah, Ronaldo, eu não posso adicionar campos não opcionais? Não pode. Então, se você tem um esquema que a compatibilidade é backward, e você tem, por exemplo, três campos, nome, endereço e idade, e aí você quer adicionar um novo campo, imagina que é o estado. Quando você adiciona esse campo estado, obrigatoriamente esse campo tem que ser opcional. Porque você está usando o tipo de compatibilidade backward assim como você pode dar atacando se você quiser você vai ver que tem outros esquemas aqui outros tipos de compatibilidade que não permitem mas o backward permite então você tem que ter muito cuidado na hora de escolher o tipo de compatibilidade porque você não vai conseguir fazer algum tipo de operação no seu esquema se você estiver usando um específico tipo de compatibilidade porque você não vai conseguir fazer algum tipo de operação no seu schema se você estiver usando um específico tipo de compatibilidade. Então nessa segunda coluna aqui, para vocês entenderem, é o tipo de operação que você pode realizar no schema. Depois eu explico as outras colunas, mas vamos passar aqui rapidamente os tipos de operação. O backward e o transitive é igual. Então assim, backward e backward e transitive, o tipo de operação são as mesmas, tá? O que muda é verificação do sistema anterior. Vou já chegar lá. Mas por enquanto só entenda que backward e backward e transitive usam o mesmo tipo de alteração. O Forward e o Forward Transitive, o que eles permitem? Que você adicione campos. E aqui pode ser campos não opcionais. Olha que legal. Então assim, se no Backward você podia adicionar campos apenas opcionais, aqui você pode adicionar campos opcionais e obrigatórios. Qualquer tipo de campo. Não tem restrição. Porém, você só pode deletar campos opcionais. Então, se você, por exemplo, tiver um campo de endereço que não é opcional, você não pode deletar esse campo. Você é obrigado a continuar com ele. O full e o full transit também permitem o mesmo tipo de alteração, que é adicionar campos opcionais e deletar campos opcionais. Apenas isso. Então, resumindo, o full você só consegue trabalhar com campos opcionais. Então, da feita que você criou o esquema, primeira versão, daqui em diante você só pode mexer em campos opcionais. Então, criar e deletar apenas opcional, sempre. Ok? E o none, você pode fazer qualquer coisa. O none, já está claro para vocês aqui, acho também claro que oi é quando você não quer e não precisa de retrocompatibilidade. É bem perigoso e pode ter que fazer sentido no seu caso, mas na maioria não faz sentido, porque, do meu ponto de vista, se você está usando esquema restre, você quer garantir algum tipo de compatibilidade para não quebrar consumidores e produtores. Então, se você está usando o noni, possivelmente você está fazendo alguma coisa errada. Talvez você está usando o noni apenas para fazer um tipo de migração e tudo certo, mas se sua solução final é noni, eu acho que eu repensaria. E tentaria usar algum desses de cima aqui, backward, forward ou full, tá? Ok? E vamos falar aqui na terceira coluna, que é a checagem. Aqui que muda, né? Se vocês perceberem, todo mundo que tem transitivo no final, ele é sempre, esse tipo de alteração é sempre igual ao anterior. Então, por exemplo, forward e forward transitive são iguais. O backward e o backward transitive são iguais. O full e o full transitive são iguais. Então, assim, em relação a alteração, é como se tivesse só três tipos, né? E o quarto que é o non, que não conta, mas vamos colocar aqui que são quatro tipos, tá? Quando a gente fala de transitivo e o normal, vamos chamar de normal aqui, qual que é a diferença? Quando você, por exemplo, vai deletar um campo, o que vai acontecer? Ele vai checar apenas com a versão anterior. Você pode fazer aquela operação. Já o transitivo, esse transitivo aqui, ele seca com todas as outras versões. O que quer dizer isso? É bem importante. Então, por exemplo, imagina que você tem três versões. Eu vou até abrir o escala de grau, que eu acho que fica mais fácil de entender. Então, só um minuto... Cadê, cadê? Pô, perdi daqui, né? Então, vamos imaginar que a gente tem aqui a versão 1 do meu esquema, tá? Eu tenho a versão 2 e eu tenho a versão 3. Perfeito? Então aqui é o meu esquema. Perfeito. Vamos voltar aqui só para entender. Então se a gente estiver usando o tipo backward, ele vai ficar só com a última versão. Então vamos imaginar que na versão 1 eu tenho dois campos o nome e idade certo? e aqui eu estou usando o tipo schema backward tá? aqui eu tenho o que? eu tenho o que eu tenho nome idade endereço o que eu posso fazer no backward eu posso adicionar campos opcionais então esse cara aqui na versão 2 ele é optional. Nome e idade são obrigatórios, aí eu evoluí para a versão 2. Nome, idade e endereço. E aí ele vai explicar quando eu crio a versão 2 o que vai acontecer. O tipo backward ele vai explicar se a versão 2 2 é compatível com a 1. Como? Verificando esse changes allowed aqui. Verificar se o que está escrito aqui está sendo obedecido apenas com a versão anterior. E confere. E aí a versão 3. A versão 3 eu posso também deletar um campo se eu quiser ou adicionar um opcional. Então posso vir aqui e colocar estável. O que vai acontecer quando eu criar a versão 3? Eu vou checar, o schema rest na verdade, ele vai checar se a versão 3 é compatível com a versão 2. Se eu estou seguindo essas regras aqui. Então, esse é o backward. Ele checa a versão nova sempre com a anterior. Então, quando eu tiver a V3, ele nem olha para a V1. Ele vai simplesmente ignorar a V1 aqui. Mas a V3, ele vai olhar com a V2. Diferente do Transitive. Quando a gente coloca Transitive isso para qualquer tipo de esquema pode ser o Forward ou Full ele vai checar a versão nova com todas as anteriores. Tá? Então ele vai pegar a V3 e checar com a V2. Pera aí, deixa eu ver se esse campo que foi adicionado é opcional. É opcional, beleza. Agora deixa eu checar a V3 com a V1. E assim vai. Então ele vai checando aqui V3 com V2, V3 com V1. Se tiver 50, ele ele vai checar V3 com 49, 48 e assim por diante. Então, esse é o transitive. E isso serve para qualquer tipo de compatibilidade. Então, o FORD é a mesma coisa. Você usa o FORD normal, ele checa a sua conversão anterior. Você usa o Ford transitivo, ele checa todas as versões anteriores ao Ford. A V1, V2, V3, V4, enfim, todas as anteriores. Beleza? Ok. Então, isso serve para todos, como eu falei. E aí o nome não faz nada. Para fechar essa parte aqui de compatibilidade, eu quero falar sobre essa última coluna aqui, que eu deixei por último, mas acredito que ela seja uma das mais importantes. Que é quem tem que atualizar primeiro. O consumidor ou o produtor. Como assim? Vamos pensar no exemplo prático, tá? Vamos pensar no backward. No backward, deixa eu colocar aqui de novo, aqui no backward está me dizendo que o consumidor pode atualizar primeiro, tá? Então imagina que eu tenho aqui a V1 vou tirar a V3 aqui eu tenho a V1 e o produtor o meu produtor está usando a V1. Então eu tenho uma aplicação em Java em Go, Java, whatever que está usando a V1. Então o produtor está produzindo mensagens com esses dois campos, nome e idade. E aí, manualmente ou de qualquer forma, você atualiza aquele esquema. Então, você adiciona um novo campo, campo endereço. Então, imagina, você foi lá no esquema REST, e ele tem um campo endereço que é opcional. Beleza. O consumidor, ele pode começar a consumir essa versão nova. Consumidor. Sem problema nenhum. Então, não vai quebrar nada. E faz sentido, né? Se você olhar aqui, como você está adicionando um campo opcional, o produtor não vai envbrar nada. E faz sentido, se você olhar aqui, como você está adicionando um campo opcional, o produtor não vai enviar nada. Então, como é um campo opcional, esse campo vai vir nulo. E aí o consumidor vai continuar a vida dele, consumindo esse novo esquema, só que com endereço vazio. Perfeito. Ninguém quebrou aqui. Assim como você deletar campo, também daria no mesmo não quebraria o consumidor, porque não? imagina que na verdade no V2 eu deletei a idade estou mandando só o nome o que vai acontecer? falando de JSON etc quando você mandar aqui o produtor vai continuar mandando o nome e idade o consumidor não olha para a idade ele não quer nem saber, então ele vai ler só o nome e está tudo certo aqui esse upgrade first quer dizer assim eu posso atualizar o consumidor primeiro e ninguém vai quebrar é diferente se eu falar de backward e tentar atualizar o produtor primeiro, o consumidor pode quebrar aqui. Então aqui só está me dizendo quem eu deveria atualizar primeiro, sem quebrar nada. Vamos só mais um exemplo aqui, Aqui me diz quem deveria atualizar primeiro. Eu vou pegar um outro exemplo, que é o Ford. O Ford me diz o contrário. Ele diz que o produtor tem que atualizar primeiro. Por quê? O Ford está me dizendo aqui que eu posso adicionar campos e deletar campos opcionais. Então, vamos supor que o produtor está produzindo na V1 aqui tem nome e idade e o consumidor está aqui na V1 também então vou colocar aqui então o consumidor está aqui na V1 também bom eu estou usando o forward que significa que eu posso adicionar campos ou deletar campos opcionais então eu vou adicionar um campo novo, vou gerar v2 e esse campo não é opcional é o endereço e o produtor vai começar a produzir na v2 o consumidor continua na v1 bom aqui, percebe que eu não vou produtor vai começar a produzir na V2. O consumidor continua na V1. Bom, aqui percebe que eu não vou quebrar também porque o produtor está produzindo um campo novo que é o endereço. E o consumidor está simplesmente ignorando esse campo. Está tudo certo. Então, eu não estou quebrando não estou quebrando de forma alguma. Em contrapartida se eu trocar isso aqui, eu vou quebrar, porque, olha só, o meu produtor está na V1, produzindo novidade, e o meu consumidor está na V2 com campo obrigatório, que é um endereço que não está sendo enviado. Então, aqui é uma situação que eu quero. É por isso que essa coluna está me dizendo quem eu deveria atualizar primeiro, tá? E aí faz sentido que seja consumidor, desculpa, produtor nesse caso, depois consumidor. Beleza? O full aqui é qualquer ordem. Então, como são campos opcionais que eu estou deletando e adicionando, se você parar para pensar rapidamente, não importa muito se é para o outro consumidor. Se é um campo opcional, não importa se esse campo existe ou não. E o none vai depender se você quer garantir algum tipo de... Aqui você não vai garantir compatibilidade, isso é verdade. Quando você está tocando o nome, você não está tendo nenhum tipo de retrocompatibilidade. Então, como eu falei, novamente, cuidado ao usar o nome. Perfeito? Então é isso, pessoal. Espero que vocês tenham gostado e até a próxima.