Skip to content

Blog

Hi folks, my name is Matheus Cruz. I am a Software Engineer currently working at MercadoLibre, where I focus on enhancing our Fury (Internal Developer Platform) to improve documentation (Documentation Platform) and facilitate load testing (Performance Test Platform) for our developers. I am also an Open Source contributor, and I'm passionate about sharing knowledge!

Talks:

Improve developer joy and productivity with Quarkus and Dapr

TL;DR

If you are already using Quarkus, you are likely familiar with the incredible developer experience it offers through features such as DevServices, DevUI, and live reload. You probably appreciate how these features enhance your experience.

Now, imagine taking that developer joy to the next level when building complex distributed cloud native applications by integrating it with the productivity and standardization provided by Dapr. While Quarkus optimizes the experience for the development process of a single application, Dapr focuses more on providing best practices and well-known patterns to help developers to build distributed applications.

In this blog post, we will explore what Dapr is and how to use it in combination with the Quarkus framework.

How Quarkus prepare reflective code to GraalVM

When running a native application, reflection cannot be used in the same way as in applications running on top of the JVM. All code that will be executed during runtime needs to be known at build time. So, how does Quarkus prepare reflective code to generate a native image using Graal SDK?

In this post, you'll see how Quarkus prepares reflection code configuration to be used by GraalVM.

Outbox pattern in Quarkus

If you need to save data into two different systems, such as persist a data in the database and then notify another service about the local changes (through RabbitMQ, Kafka, ActiveMQ, etc.), this post is for you!

In this post, we will explore how to solve dual writes problem in a distributed systems using Quarkus.

Scenario

Imagine you have an order system, and every time an order is created or its status is changed, you need to notify another system to perform an action. This scenario is common when working with microservices. In the microservice world, each microservice needs to be cohesive, have low coupling, and be deployable independently. With these principles in mind, the only way to communicate with another microservice is through the network, which often leads to an increase in dual writes. Dual writes involve writing data into two different systems simultaneously. For example, writing into the database and also writing into ActiveMQ.

In the upcoming sections, we will see this in action and look at some common mistakes people make when trying to fix the dual writes issue.

Doing it with a monolith

In a monolith, it is very simple because most of the time we have just one write operation, where we are writing into one system (commonly database). Basically, what we need is:

I can do all things in a single transaction, right?

public CreateOrderOutput execute(final CreateOrderInput input) {
    Order order = new Order(); // 1. Create the order

    // Create another domain object from the Order instance // (1)

    QuarkusTransaction.requiringNew().run(() -> {
        // 2. Persist the `order`;
        // 3. Save the order details in the database for reporting purposes;
    })

    return new CreateOrderOutput(order);
}
  1. This other object, in a microservice architecture, would probably be in another microservice.

Quarkus DevServices with JNoSQL

In this post, we will get an introduction to JNoSQL and Quarkus DevServices, two great tools that facilitate our lives as developers.

We will implement a simple DevService feature for quarkus-jnosql project. Basically, if you change to a CouchDB database the extension will provide a CouchDB container for you, if you change to a ArangoDB database the extension will provide a ArangoDB container for you!

With this post, you will be able to understand how Quarkus DevService works and get started with Quarkus extension contribution. Why not?

Deploying a Quarkus application on Kubernetes

TL;DR

We will see how to deploy in detail a Quarkus application into a Kubernetes cluster.

To achieve this goal, we will use:

Quarkus and Kubernetes

Usually, when people hear about Quarkus, they often think it's just a tool that speeds up the start of our application and consumes fewer computational resources. However, there's something very interesting as well: Quarkus is a Kubernetes-native framework with various extensions and functionalities that make working with Kubernetes easier.

Developing a Quarkus Extension

TL;DR

This post demonstrates how to create a Quarkus extension that provides three features that:

  • Notify an API regarding the application's starting status;
  • Offer a implementation class created with Gizmo;
  • Count the number of methods using @GET, @POST, @PUT, @DELETE annotations using Jandex;

Why Quarkus extension?

Quarkus is both a framework and a build time augmentation toolkit. Its principal concept is "do as much as possible during build time instead of runtime", this concept is what helps Quarkus achieve a very low startup time and a smaller memory footprint.