Versatility - Quarkus

The client-server architecture has been the de-facto standard for building applications for years. But a significant shift happened. The one model rules them all age is over. A new range of applications and architectural styles have emerged and transformed how code is written and how applications are deployed and executed. HTTP microservices, reactive applications, event-driven architecture, function as a service, and AI-infused applications are now central players in modern systems.
Quarkus has been designed with this new world in mind and provides first-class support for these paradigms. That does not mean you cannot build monoliths with Quarkus; you can do it smoothly. On the contrary, it means that the Quarkus development model morphs to adapt itself to the type of application you are developing: monoliths, microservices, CLIs, event-driven applications, functions, Kubernetes operators…​
Let’s start with the basics: HTTP microservices. You need to develop an HTTP endpoint, often called REST. You process incoming HTTP requests, and to do so, you usually need to rely on other services, such as databases or other HTTP services. Let’s take a very simple application handling elements from the periodic table.
Using Quarkus REST and Hibernate ORM with Panache, the code would be something like:
This development model should look familiar if you are a Java EE or Spring user. You expose a resource containing methods annotated with @GET, @POST to handle the different requests. Quarkus also proposes a compatibility layer with Spring APIs, so you can also use @GetMapping and @RestController.
You can use the JPA entity manager directly. You can also use Panache, an alternative that removes boilerplate and exposes active records or repository models. With Panache, the Element class would be as simple as:
Microservices tend to come in systems. Let’s now imagine you need to access another HTTP endpoint. You can use a low-level HTTP client directly; this is nothing more than repeating boilerplate code. Quarkus provides a way to call HTTP endpoints easily using the MicroProfile Rest Client API. First, declare your service as follows:
Just add a method and use annotations to describe the behavior for each call you intend to do. Then, in your resource/controller, just use the ElementService interface:
You may wonder where the URL is configured, as it’s not in the code. It should not be hard-coded because the URL likely depends on the environment. The URL is configured in the application configuration:
The URL can be updated during the deployment or at launch time using system properties or environment variables. You can even use service discovery and selection. Quarkus is not limited to HTTP. You can use gRPC or GraphQL, two prominent alternatives in the microservice space.
Application requirements have changed drastically over the last few years. Reactive architecture is increasingly becoming the preferred approach for any application to succeed in the era of cloud computing, Big Data, or IoT. Today’s users embrace applications with milliseconds of response time, 100% uptime, lower latency, push data instead of pull, higher throughput, resilience, and elasticity. However, these features are nearly impossible to achieve using yesterday’s software architecture without a considerable investment in resources, infrastructure, and tooling. The world has changed, and having dozens of servers, long response times (> 500 ms), and downtime due to maintenance or waterfalls of failures does not meet the expected user experience. We need to build better distributed systems, and that’s the motto of reactive systems.
Quarkus aids you on your journey to build reactive systems. Quarkus is based on a reactive core. Every Quarkus application is a reactive application. It uses the system resources efficiently and can handle large throughput. But, your code does not have to use reactive programming. You can mix and match three alternatives: plain imperative code, imperative code using virtual threads, or reactive code. Depending on your requirements, you will pick one or another or even mix them.
However, HTTP characteristics prohibit implementing fully reactive systems, where all the components interact using asynchronous messages passing. You can consume messages from various brokers, such as Apache Kafka, Apache Pulsar, or RabbitMQ, and process these messages smoothly:
The @Incoming and @Outgoing annotations are part of Reactive Messaging. They are used to express from which channel you are consuming and to which channel you are sending. Thanks to SmallRye Reactive Messaging, you can consume and send messages from and to different brokers and transports such as HTTP, Pulsar, Kafka, RabbitMQ, JMS, or Apache Camel.
As mentioned above, you can select among the three execution models: imperative (like shown above), reactive (using the Mutiny API, including stream manipulation), or virtual threads:
Thanks to their stellar startup time and low memory usage, you can implement functions using Quarkus in serverless environments. Quarkus provides Funqy, an approach to writing functions that are deployable to various FaaS environments like AWS Lambda, Azure Functions, Knative, and Knative Events (Cloud Events). It is also usable as a standalone service. With Funqy, a function is just:
You can use any of the Quarkus features in your function and benefit from the fast startup and low memory utilization. With Quarkus, you can embrace this new world without changing your programming language. Packaging and deployment are a breeze. Quarkus tailors your packaging to the environment you are targeting.
In recent years, AI has evolved from a niche technology to one of the most transformative innovations in IT. The rise of large language models has opened new opportunities for building more intelligent, personalized, and adaptive applications. Predictive and generative AI models are increasingly being integrated to provide smarter user exper