Todas as semanas, algumas semanas mais, outras menos, me questionam sobre RabbitMQ. Sua utilidade, se vale a pena ou não aprender ou usar, ou até se não é mais adequado criar uma tabelinha no banco para controlar o que foi processado e o que não foi.

Na prática a zona de conforto faz com que naturalmente achemos mais simples usar qualquer coisa que esteja no seu stack, como um banco SQL, NoSQL, até um Redis ao invés de usar RabbitMQ. De fato assim você elimina a curva de aprendizado, no entanto há boas chances de você estar tentando reinventar a roda, tendo de lidar com problemas que não deveria se preocupar, e ainda mais, perdendo tempo, o ativo mais importante da sua vida.

Isso acontece pela falta de percepção de valor ou falta de compreensão de que soluções especialistas lhe pouparão meses ou até anos de trabalho. Não estou desmerecendo seu esforço, no entanto há muita gente boa dedicada a entregar simplesmente um serviço de infraestrutura, como o RabbitMQ, por exemplo (são 12 mantenedores oficiais, e 76 contribuidores para o server).

Muita gente que dedica seu tempo exclusivamente a manter o projeto. E por isso, esse pessoal viu muito mais projetos, aprendeu muito mais, amadureceu muito mais, viu e sofreu com muito mais problemas (relacionados a mensageria) do que você. É uma simples questão de foco. Afinal se você está lendo esse post, é muito provável que você não faça parte da equipe que mantém RabbitMQ, e sequer é provável que você alguma vez na vida envie um PR para o projeto. Isso se dá à natureza desse blog, e dos meus posts. Portanto, creio que assim como muitos, você quer simplesmente entregar um projeto melhor, com maior resiliência, tentando não reinventar uma roda quadrada.

A série

Hoje começa uma série que tem a intenção de desmistificar RabbitMQ. A proposta é objetiva: Mostrar quais são os elementos que compõem o AMQP e consequentemente o RabbitMQ e os desdobramentos a respeito dos padrões de uso. Isso permitirá entender melhor como o standard pode trabalhar por você e ficará muito mais fácil decidir e compreender se abstrações como NServiceBus, Masstransit fazem sentido no seu cenário ou se limitam sua implementação.

A série será dividida em 2 fases, a primeira é a de explicação sobre o AMQP pela ótica do RabbitMQ, o que são Queues e Exchanges e como você cria as associações entre estes por meio de Bindings. Na segunda fase, teremos os padrões, onde você vai entender como essa simplicidade faz do RabbitMQ uma solução extremamente poderosa para mensageria.

Aviso aos caçadores de tutoriais

Já reduzindo suas expectativas, aqui vou falar de conceitos, embora use código para exemplificar algumas coisas, você não encontrará um tutorial ou um passo-a-passo. A proposta é esclarecer e permitir que você consiga estruturar um pensamento coerente a respeito de soluções baseadas em mensageria. Você aqui vai saber planejar, vai entender o que precisa ser configurado, quais tipos de exchanges usar, e como tirar proveito do RabbitMQ. Mas para conseguir implementar terá de ir na documentação ver qual a forma mais atual de colocar na prática o que vamos abordar aqui. Embora a API seja extremamente consistente, vale lembrar que a proposta dessa série não é ensinar a API/Library, ou a versão X ou Y, mas apresentar os conceitos e como desdobramento em sua implementação, quais são as possibilidades.

Próximo post

Já no próximo post vou abordar AMQP, o tema central será o standard.