É legal, agora vamos para a parte do Go, de fato. Para fazer isso daqui, a parte da coreografia, a gente desenvolveu um framework interno, o Pipes, que a gente usou a parte do uso de FX para gerenciar os pacotes, para gerenciar a ingestão de dependência, como faz a composição do que vem na solução. 

E o que isso trouxe para a gente de coisas positivas? A gente passou a ter uma configuração padronizada, todo o boilerplate da aplicação também. Ele está no próprio framework, essa questão de pegar quem que é o passo, (aqui você vê uma config, então, qual é o…), ele pega quem é o meu serviço, e de buscar e conectar já nas filas .in e .compensate. Fazer o subscribe nessas filas, para receber. Então, ele já conecta nas filas, ele sabe, depois faz a questão de mandar o publisher para o próximo passo, seja na ida no .in ou no rollback, no .compensate. E ele já... O que a gente tem aqui de código? A gente até pode abrir mais alguns exemplos, mas o que a gente quis entregar para quem estava desenvolvendo? Implemente dentro da... segue ali a estrutura básica, no main, mas, dentro da segue ali a estrutura básica no main, mas, você tem um passo que ele recebe, que ele suporta a compensação, o rollback, legal. Inicializa ele ali, nesse compensator step ali, linha 34, e implemente nessa sua interface aqui local do seu microsserviço o método handle, que é o que vai consumir do .in, o .compensante, que é para fazer o rollback. Então, aqui a gente encaixa toda a teoria que eu falei antes, que para mim estava muito abstrato no começo. Fiquei muito feliz com o resultado, para falar:  é isso. A gente consegue, então, contar a história para a galera que vai desenvolver e falar: “mas, ó, de tudo isso, o que você precisa fazer é, traz lá, usa a nossa própria lib e roda o main desse jeito e, garante que você vai ter o handle e o compensate no seu código. Porque a partir daí, quando ele dá o return aqui, ele já vai se encarregar. O Pipes que se encarrega: return com sucesso, vai lá para o tópico seguinte.” Se eu estou no handle, o tópico seguinte é o próximo passo .in. Quando no Compensate, o tópico seguinte é o próximo passo.compensate. Se der erro, vai para o passo atual .error. Esse cara já abstrai e facilita muito a vida de quem está desenvolvendo dessa forma. 

E o legal disso, quando a gente estava com esse cara já um tanto maduro, a gente já começou a usar num segundo projeto. A gente tinha o projeto principal, que estava resolvendo os problemas, e antes de mandar tudo para o ar, que a gente precisava mandar, a gente falou: “pow, isso aqui está tão legal. Tem um projeto que está começando agora e ele vai levar uns 3 meses para ir para o ar, mas já vamos começar desse jeito, porque a gente já consegue testando tudo de um jeito bem direto”.  Eu falei que a gente tinha aquele monitor dentro da estrutura para tomar algumas decisões e a gente chamou esse cara de Solenoid como aplicação interna, e a ideia dele era um conceito muito simples, estar ali monitorando a base de dados, e a partir dali, tomar decisões do que for configurado nele, para tomar decisão. Então, tem alguma coisa… quando a gente colocou também nos padrões de mensagem, quando um erro acontece, ele coloca informação sobre o erro também na mensagem, coloca na fila .error. Então, depois que a gente capturasse isso uma vez, uma análise manual, falar: “legal, esse erro, eu posso simplesmente fazer rollback”. Vamos lá e configuramos o Solenoid. Se pegar esse padrão de erro de novo nesse tópico, manda para o Compensate. Já era. Poder automatizar essas reações aos erros ali. Porque, de novo, erros são normais em tudo que a gente faz. E agregar também, fazer listagens, algumas coisas do tipo que a gente queria fazer. Em casos desses de perda, simplesmente, a gente queria fazer. Em casos desses de perda, simplesmente, a gente poderia fazer o retry que eu comentei, ou ainda um caso não mapeado naquele microsserviço para ele começar o Compensate automaticamente, ele poderia também tomar essa ação depois que a gente validar e entender o porquê daquele erro. 

Enquanto estrutura, que esse cara tem. A ideia dele era ter três entradas ali, o Kafka Watcher, o Periodic Timer, que é só um nome bonito para Cron, então ele vai rodar de tempos em tempos, vendo se tem alguma coisa ali com erro, tudo mais a fazer. E algumas ações que, vindo por API, a gente tinha não deixar a API separada da dessa parte da engine em si, então, a gente colocava via ETCd algumas configurações de quais ações tomar ali então esse cara também ou também chama direto a API e falar: “cara, faz isso agora. Pega essa mensagem aqui e manda para o Compensate”. E ele nos handlers dele faria, ou vai publicar no .in ou no .Compensate dependendo do que for.