Quarkus: Entendendo a relação entre o Mutiny e o Vert.x

#vertx #mutiny #quarkus

Se você está começando a interagir com o supersônico e subatômico Quarkus, deve ter se perguntado qual a relação entre o Vert.x e o Mutiny. São opostos? Se complementam? Vivem de forma independente? Isso e muito mais no Dev Repórter!

O que é o Vert.x?

O Eclipse Vert.x é nada mais nada menos que um kit de ferramentas focado na construção de aplicações reativas. Ele é facilmente incorporável a qualquer aplicação que rode em cima da JVM (Java Virtual Machine).

Ele conta com bibliotecas de conexão de banco de dados, comunicação com brokers de mensageria, comunicação HTTP e muito mais (pensa num kit poderoso).

A proposta do Vert.x é atuar com processamento de conexões simultâneas com menos threads possíveis. Ele verifica continuamente se há novos eventos, caso haja, ele despacha-os rapidamente para que alguém saiba como lidar com ele.

O Vert.x consegue atuar com eventos simultâneos utilizando event loop (este pode ser tema de outro artigo). Na Figura I é possível acompanhar como o Vert.x trabalha de forma otimizada através de Event Loop.

Figura 1: Estratégia de Event Loop no Vert.x

Fonte: Vert.x Doc

E o Mutiny?

O Mutiny é uma biblioteca de programação reativa orientada a eventos. Com características semelhantes ao Vert.x, ela também tem I/Os não-bloqueantes, atua de forma assíncrona. Ela é baseada na especificação do Reactive Streams bem como o Spring Reactor.

Os tipos reativos existentes no Mutiny são Uni e Multi.

Uni: representa fluxos que recebem um item ou uma falha
Multi: representa fluxos de 0 ou N itens

No trecho abaixo, é possível acompanhar o trecho onde é criado um fluxo do tipo Multi.

Multi<String> source = Multi
                        .createForm() 
                        .itens("a", "b", "c");

A relação entre Vert.x e Mutiny no Quarkus

O Quarkus é baseado no Vert.x, ou seja, em seu alicerce, encontra-se uma instância do mesmo sendo gerenciada. Exemplo: quando você desenvolve qualquer I/O, por baixo dos panos o Vert.x está atuando de forma totalmente reativa. Na Figura II é possível acompanhar onde o Vert.x se encontra na estrutura do Framework.

Figura II: Arquitetura do Quarkus

Com o Quarkus é possível você utilizar Vert.x de duas maneiras: utilizando a API "simples" Vert.x tal qual consta na documentação ou a variação com Mutiny. Segundo (ESCOFFIER, 2020), a implementação utilizando Mutiny, torna perfeita a experiência com outras APIs reativas oferecidas pelo Quarkus.

Neste artigo iremos focar na variação com Mutiny.

Na Figura III é possível acompanhar o processo de transformação com a variação do Mutiny.

Figura III: Mutiny Generator

A transformação ocorre da seguinte forma:

O pacote io.vertx para io.vertx.mutiny
métodos assícrononos para métodos que retornem o tipo Uni<T>
ReadStreams<T>serão consumidos como Multi<T>
WriteStreams<T> serão consumidos como Subscriber<T>

No trecho abaixo é possível acompanhar a implementação utilizando Mutiny, na qual permite que o desenvolvedor faça uso das representações e funções disponíveis integrando com as APIs do Vert.x através do Mutiny Generator(Figura IV).

Uni<Buffer> uni = vertx.fileSystem().readFile("my-file.txt");
uni.subscribe()
   .with(it -> System.out.println("File content is: " + it));

É importante ressaltar que o Mutiny pode ser usado de forma independente, sem nenhuma integração com Quarkus e Vert.x. Porém, na implementação do Quarkus, a relação entre as duas bibliotecas inevitavelmente irá ocorrer.
Existe uma diferença importante entre a API "simples" do Vert.x e a variante com Mutiny. Enquanto a API "simples" aciona a operação assim que o método é chamado, o Mutiny necessita que ocorra uma assinatura para que a operação seja acionada.

Conclusão

Neste artigo falamos sobre a relação entre Vert.x e Mutiny dentro do Quarkus.
Se fizermos uma análise acerca das possibilidades fornecidas pelo Quarkus, podemos considerar que há uma implementação do padrão Strategy no Code Generator. Isso porque é possível fazer uso da API "nua" do Vert.x (inclusive adoção de APIs baseadas no Reactive Streams tais como, RxJava), além da variante com Mutiny. Essa flexibilidade facilita a vida do desenvolvedor, pois ele terá a possibilidade de escolher qual a biblioteca ele deseja utilizar sem deixar de aproveitar os recursos Vert.x.

Não deixem de conferir o referencial teórico que utilizei para este artigo.