Guided: Optimizing Data Access with Quarkus

Table of Contents

1. Challenge

   Introduction and Performance Baseline

   Welcome to this guided lab on optimizing data access with Quarkus!

   You're taking on the role of a developer tasked with improving a Product Inventory microservice. The current version is fully functional and uses traditional, blocking I/O with EntityManager for database access, which can become a bottleneck under load.

   Your mission is to refactor this application using modern Quarkus patterns such as Hibernate with Panache and Hibernate Reactive to build a faster, more scalable, and resilient service.

   The starter application uses a basic EntityManager-based repository implementation that you'll progressively improve throughout this lab. info > This lab experience was developed by the Pluralsight team using Forge, an internally developed AI tool utilizing Gemini technology. All sections were verified by human experts for accuracy prior to publication. For issue reporting, please contact us.

2. Challenge

   Step 2: Refactoring to Hibernate with Panache

   Your first goal is to replace the verbose, boilerplate-heavy data access code with Hibernate with Panache.

   The application currently uses a basic EntityManager-based repository that works, but requires a lot of manual code. Panache simplifies ORM in Quarkus by using an active record pattern or a repository pattern, which drastically reduces the amount of code you need to write for common database operations.

   You will convert your standard JPA Product entity into a PanacheEntity and replace your manual repository implementation with a PanacheRepository interface. This will make the code cleaner and easier to maintain.

3. Challenge

   Step 3: Implementing Efficient Custom Queries

   While PanacheRepository provides many common methods out of the box, you'll often need to write your own custom queries.

   Panache makes this easy.

   Instead of writing JPQL strings manually, you can define a method in your repository interface that follows a specific naming convention, and Panache will automatically generate the query based on that method name.

   In this step, you'll add a method to find all products belonging to a specific category.

4. Challenge

   Step 4: Converting to a Reactive API

   Now you'll begin your transition to a fully non-blocking, reactive architecture.

   Reactive programming allows your application to handle asynchronous data streams, so it stays responsive and efficient, even under heavy load. Instead of a thread being blocked while waiting for a database or network call to complete, that thread can be released to handle other requests.

   Quarkus uses the Mutiny library for reactive programming. The two main types you'll use are:

   • Uni<T>: Represents a stream that will emit at most one item or a failure.
   • Multi<T>: Represents a stream that can emit multiple items, a failure, or a completion signal.

   As a first step, you’ll update your JAX-RS endpoint signatures to return Uni types. This change makes the API's contract reactive, even though the underlying implementation is still blocking for now.

5. Challenge

   Step 5: Implementing Reactive Panache Queries

   With your API contract updated, it's time to make your data access layer fully non-blocking using Hibernate Reactive.

   The quarkus-hibernate-reactive-panache extension provides a reactive equivalent of PanacheRepository: ReactivePanacheRepository.

   By switching your repository to this interface, all data access methods will return Uni or Multi types. Database operations will now run on a non-blocking I/O thread, freeing up your main application threads.

6. Challenge

   Step 6: Ensuring Transactional Integrity and Final Verification

   A common requirement is to perform multiple database operations as a single, atomic unit. If any part of the operation fails, all previous actions should be rolled back. This is known as a transaction.

   Quarkus makes managing transactions simple with the @Transactional annotation. When you apply this to a method, Quarkus ensures that all database work inside that method runs within a single transaction.

   In this step, you'll implement a service method to handle a business requirement: updating a product's price and stock level together.

   The service class already exists; you'll implement the transactional method. Congratulations on completing the refactoring!

   To run the application, click on the first terminal tab and run the following command:

   mvn quarkus:dev
   

   Once the application is running (it might take a minute to start up), open the second terminal tab and run the following curl command to verify the application works:

   curl http://localhost:4000/products
   

   You should see a JSON response with 3 products. The application is working!

   You can also test fetching a single product:

   curl http://localhost:4000/products/1001
   

   You have successfully transformed a traditional blocking application into a high-performance reactive microservice.