Processando Eventos de Rede Social usando EDA, Go, RabbitMQ e AT Protocol - Uma introdução.
Buenas para você que está lendo este artigo, o qual marca o início da série de artigos sobre Arquitetura Orientada a Eventos com Go, RabbitMQ, AT Protocol e a redes social Bluesky. Este artigo também marca a minha volta neste blog (que não teve lá uma presença tão forte antes né?!). E aí, vamos lá?
O que é e por quê usar o RabbitMQ?
Bem, antes de começar vou contextualizar um pouco como eu comecei a ler/estudar sobre o RabbitMQ, ok? A algum tempo atrás encerrei minha pós-graduação em Arquitetura de Software pela FIAP. E dentro da pós, tivemos demandas onde o grupo em que eu participava precisava atualizar nossa aplicação (que vinha sendo feito desde o começo, eu explico essa parte em outro momento) para inserir uma saga e começar a adapta-la para uma arquitetura atualizada onde faça uso da Arquitetura Orientada a Eventos. Como toda a aplicação é uma mistura de prova de conceito/produto minimamente viável, precisamos escolher algo de baixa curva de aprendizado e baixo custo. Diante das opções que tínhamos seguimos pelo RabbitMQ, já que seria uma boa oportunidade ali pra todos aprenderem, além de termos levantados prós e contras de todas as noças opções disponíveis no momento.
Bem o agora falando um pouco sobre o RabbitMQ, ele é um um servidor de mensageria, ou message broker, open source. O que significa que você pode baixar o seu código fonte gratuitamente e instalar localmente. Mas no caso do RabbitMQ ele também já fornece os instaladores para sistemas Linux, MacOS e Windows. Bem como uma imagem Docker (a que iremos usar nos nosso aprendizado).
O RabbitMQ por ser um servidor de mensageria, ele lidar com alguns protocolos de mensagens, como o AMQP, os protocolos próprio do RabbitMQ (que lendo um pouco achei bem interessante como eles funcionam, mas ainda estou num momento de me aprofundar e talvez traga um artigo só sobre eles) bem como o protocolo MQTT, que é bastante utilizado em Internet das Coisas, ou IoT, além de outros como HTTP, WebSockets, STOMP e o RabbitMQ Streams.
Agora que conhecemos um pouco mais sobre o RabbitMQ, vou falar um pouco mais do porque pode ser uma boa opção usá-lo: ele é resiliente, robusto e flexível, já que vem sendo desenvolvido a alguns anos e é bastante usado, permite o uso de vários protocolos além de que se você tiver um caso e uma equipe disposta, da pra customizar o RabbitMQ (lembra que ele é open-source). Uma opinião minha aqui agora, eu gostei da interface dele, apesar de simples, na minha visão está bem coerente com a documentação oficial do site deles.
Alguns dos casos de usos mais comuns é para desacoplar serviços, fazendo com que os mesmos se comuniquem de maneira não bloqueante, ou seja um serviço não para esperando o outro processar uma requisição. Com isso em mente, pode ser usado para envio de notificações, eventos, dados e um par de outras coisas mais. Lembra que eu falei que o caso de uso da minha pós era implementar uma saga? Então, foi em um sistema baseado em eventos onde usamos uma saga orquestrada com o RabbitMQ. Não sabe o que é saga? Tudo bem, penso em explicar o padrão saga em outro momento, ok?
Tá, mas o que seria Arquitetura Orientada a Eventos?
Agora que sabemos o que é o RabbitMQ, vou explicar o que é arquitetura orientada a eventos, e aí vai fazer mais sentido tanto a arquitetura, quanto o RabbitMQ. Como o nome já diz, que é bem explicativo, é uma arquitetura de solução de sistemas orientada a eventos. Talvez a dúvida suja em saber o que seriam eventos para sistemas de software, certo? Pois bem, neste caso eventos seriam mensagens para serem consumidas de maneira assíncrona, sem que um sistema pare de fazer o que deveria fazer e dependa de outro para dar continuidade nas suas tarefas.
Imagine um sistema de eventos via mensageria, como se fosse você indo fazer compras no supermercado para a sua casa. Porém, antes de sair de casa, você se depara com algumas dúvidas sobre alguns itens que deveria comprar, neste caso você pode mandar uma mensagem, via Whatsapp, Telegram, ou outra aplicação que você usa, para a pessoa, ou pessoas, com quem você mora ou para alguém de confiança. Sendo assim, ao mandar a mensagem, você não espera que te respondam para ir ao supermercado, você vai ao supermercado e espera que te respondam enquanto você está no caminho, ou já colocando os itens no carrinhos (e torcendo para que te respondam a sua dúvida).
Ou seja, você seria um sistema que precisa fazer uma tarefa (ir ao supermercado fazer compras) e precisa de algumas informações extras (dúvida de alguns itens), porém essas informações não são impeditivas para que você realize sua tarefa. Desta forma você envia uma mensagem (um evento) para que outra(s) pessoa(s) lhe responda(m) e assim você possa concluir completamente sua tarefa, ou parcialmente sua tarefa.
Em uma arquitetura orientada a eventos, existem sistemas que costumam publicar mensagens (eventos) em softwares de mensageria, como o RabbitMQ, Kafka, PubSub, SQS, entre outros. Estes sistemas que publicam as mensagens, que produzem os eventos, são conhecidos como producers. Já os eventos que vão ficar ligados aos softwares de mensageria, esperando os eventos chegarem para serem consumidos e executarem alguma demanda relacionada as mensagens, são conhecidos como consumers. E por último, mas não menos importante, os softwares de mensageria são conhecidos como routers, pois eles que vão direcionar a rota que cada mensagem deverá tomar e assim entrega-las para os seus devidos consumidores.
Claro que a Arquitetura Orientada a Eventos tem seus prós e contras e deve ser sempre bem avaliada o seu uso, mas para não extender demais, posso fazer um outro artigo só para Arquitetura Orientada a Eventos e explicar melhor.
E o que tem haver o AT Protocol com BlueSky, Arquitetura Orientada a Eventos e o RabbitMQ?
Tudo haver, mas talvez não seja tão claro ainda e está tudo bem. Vou explicar agora, então acalma a pressa e da um gole nessa água aí do lado.
Vamos começar falando da nova rede social, a BlueSky. Ela é uma rede social de micro blogging, bem parecido com o X, antigo Twitter. A diferença aqui de fato, mora no fato que ela é uma rede federada, ou seja, cada ação que você faz na rede social, como curtir um post ou seguir alguém, gera um evento. Esses eventos são transformados em mensagens e enviadas, para outros sistemas e plataformas através do AT Protocol (Authenticated Transfer Protocol), em tradução livre seria Protocolo TA (Protocolo de Transferencia Autenticada). Através desse sistema, as diferentes plataformas que utilizam o AT Protocol conseguem se comunicar e sincronizar as informações. É como um grande bate-papo entre as redes sociais, onde cada uma compartilha as novidades com as outras.
Logo nos temos um oceano de dados e informações cruzando em tempo real em diversos sistemas e é aqui que entra o Go e o RabbitMQ, pois durante os próximos artigos, vamos nos aprofundar mais nesse mundo e criar uma aplicação que irá consumir esse grande volume de dados, de forma eficiente. O que vamos fazer com esses dados ainda é segredo para não dar spoiler, mas acho que será bem interessante.
E agora?
Bem, agora por enquanto é isso, mas para dar um gostinho do que vamos fazer, além desta introdução, deixo um rascunho do sistema que vamos estar desenvolvendo.
Espero que essa introdução (e meu retorno ao blog) tenha lhe agradado e instigado acompanhar essa empreitada que estarei fazendo. Tentarei fazer algo simples, didático, mas bem funcional. Porém, o foco será ser simples e fácil de entender, então algumas boas práticas serão deliberademente omitidas e não aplicadas, mas isso não quer dizer que você não possa comentar que sentiu falta de algo, comente, aponte, critique, elogie e sempre ajude a compartilhar o conhecimento.
Então é isso, até mais e te aguardo no próximo artigo da série!