How Quarkus Integrates MicroProfile and Spring
When developing Java microservices, it is often believed that Eclipse MicroProfile and Spring boot – These are separate and independent of each other APIs. By default, programmers typically use the APIs they are used to, since learning new frameworks and runtime components takes a lot of time. Today we will try to simplify the development of some popular MicroProfile API for Spring Developers and show how to simultaneously use the Spring API and new useful features Quarkus.
If a little more detailed, we will first look at the scope and details of how Quarkus supports Spring APIs to show Spring developers how to use the MicroProfile API in their daily work. Then we will talk about the MicroProfile API, which will be useful for Spring developers when creating microservices.
Why Quarkus? Firstly, this is live coding, that is, automatic reloading of any changes to the MicroProfile API, Spring API and other Java APIs, which is performed with just one command: mvn quarkus: dev. Secondly, considered in our example the Person service (it is compiled from the Spring, MicroProfile, and JPA APIs into a binary file using the native GraalVM image) starts in just 0.055 seconds and takes about 90 MB of RAM (RSS) at the endpoint of the RESTful application. Moreover, its compilation itself is performed with just one command: mvn package -Pnative.
We will not go into the details of MicroProfile, but only try to help Spring developers understand how in Quarkus you can use Spring APIs along with MicroProfile APIs.
Containers and Kubernetes
In order not to overload this article, we will consider here only the high-level aspects of support Kubernetesbecause it is important to understand. Quarkus is positioned as a Java stack for Kubernetes, it is designed to minimize memory consumption and startup time of Java applications and services, and, as a result, increase the density of their placement on the host and reduce overall costs.
Quarkus also supports auto-generation Kubernetes resources and offers guides Deployment on Kubernetes and Red Hat OpenShift Platforms In addition, Quarkus automatically generates the Dockerfile.jvm (JVM packaging) and Dockerfile.native (native binary packaging) files needed to create containers.
Finally, focusing on Kubernetes as the target deployment environment, Quarkus does not use Java frameworks in cases where similar functionality is implemented at the level of the Kubernetes platform itself. Table 1 shows a map of the functional correspondence of Kubernetes and the typical Java frameworks used by Spring developers.
Table 1. Functional mapping map for Java frameworks and Kubernetes.
|Functional||Traditional Spring Boot||Kubernetes|
|Configuration||Spring cloud config||Config Maps / Secrets|
|Load balancing||Ribbon (client side)||Service, Replication Controller (server side)|
Compiling and running the code from the example
In this article, we refer to project examplewhere the Spring and MicroProfile APIs and even the very same Java class are shared. The code from this example can be compiled and run from the command line, see the README.md file for more details.
Spring Framework APIs
Quarkus supports a range of Contexts and Dependency Injection (CDI) APIs and Spring Dependency Injection APIs (Spring DI). If you work with MicroProfile, Java EE and Jakarta EE, you are already familiar with CDI. On the other hand, Spring developers can use the Quarkus Extension for Spring DI API to ensure compatibility with Spring DI. Examples of the use of the supported Spring DI APIs are given in Table 2.
IN project from our example used by both CDI and Spring Dependency Injection. For more information and examples on this topic, see the Quarkus manual, called Spring DI Guide.
Table 2. Examples of using the supported Spring DI APIs.
|Supported Spring DI Features||Examples|
MicroProfile users will enjoy Quarkus supporting JAX-RS, MicroProfile Rest Client, JSON-P and JSON-B as their primary web programming model. Spring developers will be pleased with the recent support of the Spring Web API in Quarkus, in particular, the REST interfaces. By analogy with Spring DI, the main goal of supporting the Spring Web API is for Spring developers to use the Spring Web APIs along with the MicroProfile APIs. Examples of use of the supported Spring Web APIs are given in Table 3, and additional information and examples on this topic can be found in the Quarkus manual, which is called Spring web guide.
Table 3. Examples of using the supported Spring Web APIs.
|Supported Spring Web Features||Examples|
Spring data jpa
MicroProfile users will also like Quarkus to support JPA using Hibernate ORM. There’s some good news for Spring developers too: Quarkus supports common annotations and Spring Data JPA types. Examples of using the supported Spring Data JPA APIs are shown in Table 4.
IN project from our example uses the Spring Data JPA APIs, and more information is available in the Quarkus tutorial called Spring Data JPA Guide.
Table 4. Examples of use of the supported Spring Data JPA APIs.
|Supported Spring Data JPA Features||Examples|
|Derived query methods|
Fault tolerance designs are critical to preventing cascading failures and building robust microservice architectures. Spring developers have been using circuit breakers for fault tolerance for many years. Hystrix. However, Hystrix has not been updated for a long time, but MicroProfile’s Fault Tolerance is now actively developing and has already had several years of production use. Therefore, to increase the reliability of services in Quarkus, it is recommended to use the MicroProfile Fault Tolerance APIs, examples of which are given in Table 5. For more information about this, see the Quarkus manual. Fault Tolerance Guide.
Table 5. Examples of using the supported MicroProfile Fault Tolerance APIs.
|MicroProfile Fault Tolerance Features||Description||Examples|
|@Asynchronous||Running logic in a separate thread|
|@Bulkhead||Limit the number of concurrent requests|
|@CircuitBreaker||Smart crash management and crash recovery|
|@Fallback||Alternative logic call in case of failure|
|Retry||Retry on request failure|
Service Check (Service Health)
Kubernetes platforms monitor container health using special services. So that the underlying platform can monitor services, Spring developers usually use the customizable HealthIndicator and Spring Boot Actuator. In Quarkus, this can be done using MicroProfile Health, which by default perform a liveness check, but can be configured to simultaneously check liveness and readiness. Examples of using the supported MicroProfile Health APIs are shown in Table 6, and more information is provided in the Quarkus Guide Health guide.
Table 6. Examples of use of the supported MicroProfile Health APIs.
|MicroProfile Health Features||Description||Examples|
|@Liveness||Platform reloads failed containerized applications|
host: 8080 / health / live
|@Readiness||The platform will not send traffic to containerized applications if it is not ready|
host: 8080 / health / ready
Applications provide metrics either for operational purposes (to monitor SLA performance indicators) or non-operational (business SLA indicators). Spring developers provide metrics using the Spring Boot Actuator and Micrometer. In turn, Quarkus uses MicroProfile Metrics to provide basic metrics (JVM and operating system), vendor metrics (Quarkus), and application metrics. MicroProfile Metrics requires that the implementation support JSON and OpenMetrics (Prometheus) output formats. Examples of using the MicroProfile Metrics API are shown in Table 7.
IN project from our example MicroProfile Metrics are used to provide application metrics. For more information, see the Quarkus manual. Metrics guide.
Table 7. MicroProfile Metrics API Usage Examples.
|MicroProfile Metrics Features||Description||Examples|
|@Counted||Indicates a counter that counts the number of calls to an annotated object.|
|@ConcurrentGauge||Indicates a gauge sensor that counts the number of parallel calls of an annotated object|
|@Gauge||Indicates a gauge that measures the value of an annotated object.|
|@Metered||Indicates a meter that monitors the frequency of calling an annotated object.|
|Metric||An annotation containing information about metadata when a request is made to enter or produce a metric|
|Timed||Indicates a timer that tracks the duration of an annotated object.|
Application metrics localhost: 8080 / metrics / application
Basic metrics localhost: 8080 / metrics / base
Vendor metrics localhost: 8080 / metrics / vendor
All metrics localhost: 8080 / metrics
MicroProfile Rest Client
Microservices often provide RESTful endpoints that require appropriate client APIs. To use RESTful endpoints, Spring developers typically use a RestTemplate. Quarkus also offers MicroProfile Rest Client APIs to solve this problem, examples of which are given in Table 8.
IN project from our example RESTful endpoints are used with the MicroProfile Rest Client. Further information and examples on this topic can be found in the Quarkus manual. Rest Client Guide.
Table 8. Examples of using the MicroProfile Rest Client APIs.
|MicroProfile Rest Client Features||Description||Examples|
|@RegisterRestClient||Registers a typed Java interface as a REST client|
|@RestClient||Marks the implementation of an instance of a typed REST client interface|
|Invocation||Invokes a REST endpoint|
|mp-rest / url||Specifies a REST endpoint|
In this blog, which is primarily useful for Spring developers, we briefly looked at how to use Spring APIs in Quarkus together with MicroProfile APIs to develop Java microservices and then compile them into native binary code, which saves hundreds of megabytes of RAM and starts in a matter of milliseconds.
As you already understood, additional information on support for the Spring and MicroProfile APIs, as well as a host of other useful information, can be found in Quarkus Guides.