Quarkus in Action

Why Quarkus and Why This Book?

Holly Cummins: Hello and welcome to GOTO  Book Club. I'm really excited because I get to talk to some of my colleagues today about one of my favorite subjects, which is Quarkus. So we're going to be talking about Quarkus in Action. Now before we do introductions, have you all got your copies of the book with you?

Authors: Yes!

Holly Cummins: Okay. We can do coordinated book waving, although I'm digital only, so I can't do my book wave. But you two can do a big wave. Signed by us!

Before we jump into the contents of the book, we should probably introduce you all. Maybe starting with Martin?

Martin Stefanko: Thanks. So my name is Martin Stefanko. I started contributing to Quarkus since version 0.12. I worked before on WildFly and JBoss application servers for about eight years, and now for over two years I've been part of the core Quarkus team working on several extensions.

Jan Martiška: Hi, I'm Jan. My history is very similar to Martin's. I also started contributing to Quarkus very early on as a Red Hat employee. Now I'm an IBM employee because we were moved from Red Hat to IBM. I also worked on WildFly and JBoss application server in the past.

Holly Cummins: Great. Today I want to talk partly about the contents of the book, but also about the process of writing the book because I think for both of you, is it your first book?

Authors: Yes.

Holly Cummins: It's such a big, exciting thing, isn't it?

Before we even start about why you wrote the book, it might be useful to think about why people would want to read the book. The answer is probably obvious—people who would want to use Quarkus would want to read the book. So let's go two steps back and say, why would people want to use Quarkus? Why is it interesting and exciting?

Martin: That's a question we get all the time. I would split it into several different things. For me, because I'm a field engineer in my day job, it's definitely the developer experience that Quarkus provides. The dev mode, which is an integral part of Quarkus and we use extensively throughout the book, is probably the single most productive tool that I ever encountered in my career. I can go so fast that I'm not even able to catch up with everything that I'm doing at the same time. You'll see this inside the book heavily.

Jan: To the developer experience, I would also add continuous testing that allows you to run tests in the background. You don't even know they're running until they start failing. There are more reasons—things like native mode integration, fast performance, blazing fast startup time thanks to build time initialization, which is something very innovative and new in the Java world. The application gets partially initialized during the build, and when you actually start the application, it's blazing fast because most of the initialization steps have already been done.

It has a growing ecosystem of integrations. It glues together all the frameworks that people know and like. So it's not like you need to learn a lot of new frameworks. If you're a Jakarta EE developer, you already know most of them. Quarkus just glues them together.

Martin: Just to add on this—running dev mode is something you'll do in the morning and then forget about it until you see some green changes. There are so many features on top of continuous testing—the dev services, the UI, etc., which we have a separate chapter about in the book. All of this is encompassed in dev mode.

Holly Cummins: I want to go back to one of the things you were saying at the beginning, Martin, about the productivity and developer experience. Sometimes now there's this conversation that says nobody needs to care about developer experience because everybody can just use an LLM to write the code. But we spend a fairly small amount of our time actually writing code as developers, and much more of our time reading code. The fact that Quarkus has this really beautiful, clean, compact syntax that's also really familiar is so important, even if you've got an LLM spitting out the code, because no one wants lots of LLM-generated code.

Martin: Exactly. Quarkus is one of the frameworks pushing LLM integrations in Java. The integration with LLMs is so easy that sometimes you'll even forget what is Quarkus and what is actually the LLM. It has happened to me.

Holly Cummins: Yeah, the first time I used that, I thought it would be harder.

Jan: Very soon there will be a new feature that introduces an AI assistant into Quarkus. When writing your application, you can get assistance with that. It knows all the internal details about Quarkus because that's completely new. Obviously the book doesn't talk about it, but I wanted to point out that it's coming soon.

Holly Cummins: Yeah, it's very cool. What inspired you to write a book? You like Quarkus and you have evenings and weekends free, and then you say, no, I wish to change that.

Martin: I'll take this one because I started it. Actually, I met someone at a conference, and he told me that the thing he regrets is that he didn't write a book before he was 30. So I set a goal for myself that I wanted to write a book before I was 30.

I reached out to some internal people at Red Hat, and they pointed me to Manning. By chance, somebody was already interested in writing "Quarkus in Action," but they dropped out for some reason. They asked me if I wanted to take it, and I said, hell yeah.

That's it, more or less. Then I reached out to the Quarkus team because I didn't feel confident enough that I could write the book myself, or at least it would take a very long time with my day job. So Jan volunteered to help, and here we are.

Holly Cummins: I think it definitely makes sense to have help both because things are always better with company, but also because in something like Quarkus, where it's changing so fast—you mentioned that there's always new stuff coming—you need to work in parallel to be able to get ahead of the wave of the coming technology.

Martin: You don't know how right you are. If I remember correctly, we started with Quarkus version—

Jan: The first was Quarkus 2.0 something.

Martin: And the final version is 3.15. So you understand how many rewrites we needed to do throughout the process.

Holly Cummins: You just want your colleagues to stop working so that you can finish it!

Martin: The fun part is that the actual code was easy because we have this upgrade mechanism, OpenRewrite. So updating the code is very easy. But you have 300 pages to go through and update the versions.

Holly Cummins: And of course updating screenshots is no fun.

Jan: Yeah. Any kind of update of something was actually quite hard. That's also one of the aspects of multiple people working on a book, because your work depends on each other. When one person decides later to change something in a previous chapter, that has to be communicated and the following chapters have to be adjusted. That means the other person will have to do the adjustments too. And yeah, it's hard.

Inside the Book: Structure and Coverage

Holly Cummins: Can you talk through the structure of the book and what you decided to include, and then maybe what you didn't include and why?

Jan: Let's skip quickly through the table of contents. The book is split into three parts. The first part is called "Getting Started with Quarkus," which is the introduction, the motivation, why you want to use Quarkus and what the basic principles are. Then within the first part, there's chapter two that lets you write and run your first Quarkus application where you get to see the benefits of dev mode.

Then in chapter three, we show all the development experience goodies. Developers really like chapter three because it shows all the developer productivity things.

Then the book starts developing a big project called Acme Car Rental. It's a set of microservices—a system for managing a car fleet for a car rental company. While reading the book, the reader will create this set of microservices. It's five microservices connected via different protocols and using different databases.

In part two of the book, we mostly write these applications. Each chapter is focused on some particular framework or technology that is used. We deliberately made the system quite complicated by introducing all of the frameworks that we could use because we wanted to show just a little bit of everything.

It shows how to develop REST APIs, REST clients, GraphQL APIs, GraphQL clients, gRPC services, gRPC clients. Then we get to a chapter about testing. There's a chapter that shows how to develop secure applications, combined with developing frontends with Qute. Then there's a chapter about using databases and Hibernate object-relational mapping. There's something about reactive programming and something about reactive messaging. That concludes part two.

Part three is about deploying Quarkus in the cloud. We containerize the applications that we created during part two and deploy them in OpenShift. Then the last chapter, number 12, is about writing your own extension for Quarkus. If somebody decides to integrate their own framework, this chapter will give you the basic instructions on how to do that.

Martin: To respond to the second part of the question about why we chose what we chose and what we left out—more than anything, the biggest limitation was the number of pages. Quarkus now has around 850 to 900 extensions, I'm losing track. We basically tried to design a system that was purposely overcomplicated as much as we could. We used different databases—reactive, hybrid, NoSQL—different HTTP approaches. So we did REST, gRPC, GraphQL. By the end of the book, when you run all five services in dev mode, it will spin up another 12 containers just for the dev services, which is already hard to run on machines that aren't so strong. So we needed to limit it there.

Holly Cummins: That makes me laugh about the overcomplicated part because I can just imagine that if it was a real application and you presented it to an architecture review board, somebody would be like, "This is CV-driven development. You do not need to use all of these things." But of course, for learning, that's exactly what you want.

Martin: Exactly.

Holly Cummins: So you mentioned there are 800 or 900 extensions in the ecosystem. Do you happen to know what proportion of those are in the book, or how many extensions are covered?

Jan: I did try to count by looking at the POM files and filtering out all the extension artifacts and dependencies. I got to 29 declared in the POMs, but it's definitely more because some extensions are brought in transitively. But we have 29 distinct extension dependency declarations in our POMs.

Holly Cummins: So 29 headline features that are covered. Cool.

Martin: The intention was to showcase the use cases for application development. We didn't focus on showcasing all the extensions because there are at least five databases that we didn't include because we just don't have the space.

Holly Cummins: What section do you think people will be most surprised by?

Martin: I would say for somebody who never touched Quarkus, definitely chapter three, because that's a deep dive into dev mode. That's definitely the most interesting feature. But for somebody who is already familiar with that, I would probably say reactive programming, because we're stepping back from it and people forget that it's built on top of Vert.x and Mutiny reactive core. So you're free to choose if you want to use reactive or just a little bit of reactive, which we're also showcasing.

Jan: I definitely agree with Martin. I would also add that maybe the cloud section, because some people might not know that Quarkus actually generates Kubernetes manifests. So it's very easy to deploy into Kubernetes.

Martin: We decided to do Kubernetes, OpenShift, and also serverless deployments. So you have everything in there.

Holly Cummins: Cool. I was just in a talk the other day about what Quarkus does, and it was about application-driven infrastructure. I think that ties quite nicely with what Quarkus is doing in terms of getting the infrastructure declaration driven by what's in the application rather than the other way around.

I can share—this is a little one—but when I was reading the book, one of the things that surprised me: I think no matter how long you've been working on Quarkus, there's always going to be things that are surprising. I use code.quarkus.io all the time, and I had no idea that it had a REST API. So I was reading that and was like, oh cool, learned something.

What the Authors Learned

Holly Cummins: For you personally, from where you started to where you are now, which sections did you learn the most from in the process of writing them?

Jan: For me that was probably messaging because I had very little knowledge about messaging before. Luckily Martin did most of the work writing that chapter, so I didn't have to do all the research by myself. I had zero knowledge about RabbitMQ, for example. So this was completely new to me.

Martin: For me it was definitely frontend—I'm on the other side of the spectrum. I use terminal for everything. I only use code.quarkus.io if I need to do a demo. So for me it was mostly frontend, even if that's one specific way to do frontend. But Quarkus does a very good job describing the overall approach. Then I would say GraphQL and gRPC because that's not something I touched before.

Holly Cummins: That makes sense. Let's dive a bit deeper. You say you learned a lot about messaging. What is the Quarkus approach to messaging and what does it bring beyond just using a RabbitMQ library without any extra Quarkus support?

Jan: There's this general API that abstracts you away from different messaging providers. It's basically based on the MicroProfile Reactive Messaging specification. Quarkus lets you use that and your code can be abstracted away from the underlying provider. You can use reactive programming so you don't have to block your threads while waiting for a response. It works together very nicely.

Martin: But you don't need to write reactive code to use messaging.

Jan: Of course you do not.

Holly Cummins: It does feel like a natural fit, doesn't it? But yeah, you're totally right. Another thing that's really helpful is Quarkus dev services. For messaging, if you're trying to write a messaging application, you really need to have the messaging infrastructure there, which can be a pain. Then you need multiple applications talking to the same one and you have to coordinate it. What Quarkus does with dev services—using test containers to stand up your messaging backend but then also allowing them to be discovered by other Quarkus applications so you can test in that way—is pretty cool.

Martin: And you'll see that by the end when you run these services which are connecting to Kafka, there's only one instance and everything magically connects together.

Holly Cummins: Very nice. So I've got the same question for you, Martin. Not about messaging because that would be too easy. What is the Quarkus approach to frontend?

Martin: Well, there are so many options you can choose from. We chose Qute just because we wanted to make it as simple as possible for the book. That was only a single page of HTML. For me, it was more learning where to put everything, how to configure everything so it's exposed properly. But it also opened a way for me. Actually after this chapter, I started writing my first extensions.

In general, you can use possibly any JavaScript framework or even libraries which are integrated in Maven artifacts which are included in your JAR. We have one person who is very passionate about frontend on the team, and he comes with a lot of great ideas all the time. So definitely check out the Quarkus documentation because we could speak about this for the whole 30 minutes.

Holly Cummins: We would run out of time to list everything.

Jan: You can also use Java-based frameworks, for instance. You have integration with Vaadin, which is very nice.

Martin: Definitely. If there is no integration for your current frontend, that's probably something we can do. But I don't think there's something that we don't have.

Holly Cummins: Yeah, I always have a soft spot for Vaadin because I went to visit the Vaadin team once in Finland. It was in February, so it was very cold. I arrived and they offered me ice cream, which was not what I wanted in February in Finland, but it was ice cream so I took it. Good folks over at Vaadin—they give visitors ice cream.

Going back to the book—in the process of writing a book, there's probably always that moment when you're questioning your life choices and thinking, "I used to think Martin was a friend." So what section or external event made you question your life choices? Or was it just happy all the way through?

Jan: For me, the containerization and Kubernetes thing was a bit harder to comprehend. There are multiple things that come into play—managing the images, building the images, pushing them to a registry. It all can get very complicated. Even though Quarkus really does what it can to make your life easier by generating Kubernetes manifests, you still have to manage the images.

I remember we had a lot of problems because I use Podman on my machine and Martin uses Docker. Even though they should work the same, they actually don't. So we had some issues writing Docker Compose scripts in a way that they would work on my machine and Martin's machine and the readers' machines.

Martin: I also have Podman just to say, and this is not an issue of Quarkus, this is an issue of Podman.

Holly Cummins: Yeah, it's just such a complex ecosystem, isn't it?

JVM vs Native: Essential Guidance

Holly Cummins: I was rereading the book before we talked, and one of the things I really liked about what you did was that you talk really early on about when people should use native and when they should use JVM. I see people getting muddled about this because Quarkus makes native way easier. But then people think, oh well, they have to use native with Quarkus. What advice do you have for people about when to use JVM and when to use native?

Martin: Actually, I'm very glad that you asked that because this question comes all the time, everywhere when we talk about Quarkus. Many people associate it that native compilation is the end goal that you have to do before production, which is totally not true. I'm very happy that I was able to finally draw this diagram, which I'm always drawing to everybody at every conference, in the book.

Basically the problem with native compilation is that you'll get very fast startup and very low memory usage in the binary. But because it's using ahead-of-time compilation with the closed world assumption, that means you freeze your world at the time of compilation. The performance is high, but it's static in time.

With JVM, you'll start definitely lower with performance—by performance I mean throughput per second. You'll start lower with the performance, but as the JVM optimizes your code and JIT does its magic, you will always get better performance if you let the JIT do its magic long enough. GraalVM is trying to get there, but usually, at least by now, it's still a big enough difference that if you are running services for some time—typical microservices or normal applications—then definitely stick to JVM.

If you really want to do serverless deployments where you really have an application that needs to start fast and it doesn't live long, then native makes sense. Or CLIs, which I love.

Holly Cummins: Yeah, I saw a fantastic demo a couple of years ago of Quarkus for CLIs, and the native start was so fast that you could get the autocomplete. It looked instantaneous in terms of perception, but under the covers it was firing up a native image, asking what options were available, and then bringing it back down again. It was very cool.

Martin: I actually have this kind of use case right now because in Slovak and Czech languages, we have a lot of diacritics—small characters—which I am very lazy to write because I can really write ASCII. Now I have an online application that will send my clipboard to an LLM and they give me diacritics and put it back into my clipboard.

Holly Cummins: Right! Now I'm fascinated by that because I am hopeless with any kind of character decorations because I'm not accustomed to them. But I assumed that you would just be doing them instantly. But I feel a bit better that I'm so bad with them now.

Unexpected Sidebar

So the last question—I know we already waved our books, which is quite exciting. I think writing a book is a little bit like raising a child in terms of how much you put into it and then you send it off into the world. But I know, Jan, that you just got a puppy recently, and I also just got a puppy recently. So now I know that raising a puppy is a little bit like raising a child, which means raising a puppy is like writing a book. The internet is for cats, but the secondary purpose of the internet is for puppies and dogs. So I don't know if your puppy is convenient for us to be able to see?

Jan: Yeah, just give me a minute to find them. My kids are playing with them right now. [retrieves puppy]

This is Teddy. She's two and a half months old. We have no idea what race she is. She's a crossbreed of something and something, we have no idea. Just today, she found a dead bird in the garden and tried to bring it into the house and eat it.

Holly Cummins: That was the equivalent of the containers chapter, right? Of like, why did I do this to myself?

Jan: Yes!

Martin: [shows cat] That's my little demon. Her name is Scratchy because she's scratching. We love her. I also have a dog, but I'm at a standing desk right now, so I don't really want to hold her.

Holly Cummins: Oh, amazing. Thank you very much both for the chat and for the puppy cam. Absolutely fantastic. I have read the book, I loved the book. I would absolutely encourage people who want to know more about Quarkus, but also people who know Quarkus in a lot of depth, because there's so much in the book that you will absolutely learn something from it. So again, thank you very much.Martin & Jan: Thank you, Holly Cummins, for having us. Thanks for having us.