About Quarkus, Munity and Vertx

Eclipse Vert.x is a toolkit for building reactive applications. It is designed to be lightweight and embeddable. Vert.x defines a reactive execution model and provides a large ecosystem.

Quarkus is based on Vert.x, and almost all network-related features rely on Vert.x. While lots of reactive features from Quarkus don’t show Vert.x, it’s used underneath. Quarkus also integrates smoothly with the Vert.x event bus (to enable asynchronous messaging passing between application components) and some reactive clients. You can also use various Vert.x APIs in your Quarkus application, such as deploying verticles, instantiating clients…

To asynchronously handle the HTTP request, the endpoint method must return an io.smallrye.mutiny.Uni (requires the quarkus-resteasy-mutiny extension):

USING ECLIPSE VERT.X API FROM A QUARKUS APPLICATION

• Architecture
• Solution
• Bootstrapping the application
• Accessing the managed Vert.x instance
• Using Vert.x Core API
• Using Vert.x stream capability
• Using the event bus
• Using Vert.x Clients
• Going further

Vert.x is a toolkit for building reactive applications. As described in the Quarkus Reactive Architecture, Quarkus uses Vert.x underneath.

Quarkus applications can access and use the Vert.x APIs.

This guide presents how you can build a Quarkus application using:

• the managed instance of Vert.x
• the Vert.x event bus
• the Vert.x Web Client

It’s an introductory guide. The Vert.x reference guide covers more advanced features such as verticles, and native transports.

Mutiny – An event-driven reactive programming API

Mutiny is very different from the other reactive programming libraries. It takes a different approach to design your program. With Mutiny everything is event-driven: you receive events, and you react to them. This event-driven aspect embraces the asynchronous nature of distributed systems and provides an elegant and precise way to express continuation.

Mutiny offers two types that are both event-driven and lazy:

• A Uni emits a single event (an item or a failure). Unis are convenient to represent asynchronous actions that return 0 or 1 result. A good example is the result of sending a message to a message broker queue.
• A Multi emits multiple events (n items, 1 failure or 1 completion). Multis can represent streams of items, potentially unbounded. A good example is receiving messages from a message broker queue.

These two types allow representing any type of interactions. They are event sources. You observe them (subscription) and you get notified when they emit an item, a failure, or, in the case of a bounded Multi, a completion event. When you (the subscriber) receive the event, you can process it (e.g., transform it, filter it). With Mutiny, you are going to write code like onX().action(), which reads as “on item X do action”.

If you want to know more about Mutiny, and the concepts behind it, check the Mutiny Philosophy.

• For Details : Read Quarkus – Mutiny – Async for bare mortal

Reference

• https://quarkus.pro/guides/vertx.html
• https://quarkus.pro/guides/getting-started-reactive#mutiny
• https://vertx.io/docs/vertx-web-client/java/
• https://quarkus.io/guides/getting-started-reactive
• https://quarkus.io/blog/mutiny-back-pressure/
• https://smallrye.io/smallrye-mutiny/pages/philosophy
• https://vertx.io/docs/vertx-web-client/java/#_using_the_web_client