Hello and welcome to GOTO Book Club. I'm really excited because I get to talk to some of my colleagues today and we get to talk 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? >> Yep.

>> Yay. We can do like coordinated book-waving. Although I'm digital only, so I can't do my book wave, but you two can do your book wave.

>> And signed by us. >> Yay. Although it's kind of easy to sign your own copy of a book, isn't it?

>> So before we sort of jump into the contents of the book, I guess we should probably introduce you all.

So maybe do you want to just, yeah, start with a little bit of who you are and how you came to be involved with Quarkus and that kind of thing?

>> Okay, thanks, Holly. So my name is Martin Stefanko. I basically started with Quarkus contributing since 0.12.

I used to work before in Wi-Fi or JSOP application servers for about 8 years and now for almost two years, I am part of the core Quarkus team working on several extensions.

>> Hi, I am, and 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 and also worked on WildFly/JBoss application server in the past. So yeah, it's very, very similar.

>> Great. And today I want to talk sort of partly about the contents of the book, but also partly about sort of the process of writing the book, because I think for both of you, is it your first book?

Is that right? >> Yes. >> Yes. >> Yeah. Such a sort of a big, exciting exciting thing, isn't it?

>> Yeah. >> Before we sort of even start about like why you wrote the book, I guess it might be useful to think about like why people would want to read the book.

And I was sort of thinking about that and I was like, well, the answer is probably obvious for this, which is that people who would want to use Quarkus would want to read the book.

So maybe actually let's like go two steps back and say why would people want to use Quarkus?

Why is Quarkus interesting and exciting to—well, obviously it's exciting to you because you wrote a book about it, but why would it be for other people as well?

>> So that's my question that we are getting all the time.

Probably I would split it into several different things for me because I'm still an 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 are using it extensively throughout the book is basically the 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.

And you will see this inside the book heavily. And, uh, do you want to talk about the performance?

Uh, yeah, to the developer experience, I would also add that there's this thing called continuous testing that allows you to also run tests in the background.

You you don't even know about them that they are running until they start failing. And yeah, more more reasons there are the like things like a native mode integration, fast good performance, start blazing fast startup time thanks to build-time initialization, which is something uh very innovative and new in the Java world that the application gets partially initialized already during the build.

And when you actually start the application, it it's it's blazing fast because most of the initialization steps have already been done before.

And it has a growing ecosystem of of integrations or 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.

You can, if you're a Java enterprise Java developer, you already know most of them and Quarkus just glued them together.

Just to, sorry, just to add on this, like, I definitely agree that running the dev mode is something that you will do just in the morning, then you will forget about it until you see some like green changes to red.

And like there are so many features on top of like continuous testing, the services, the UI, et cetera, which we have a separate chapter about in the book, which is encompassed in this dev mode that like we cannot list everything here right now.

And I just I want to go back to one of the things that you were saying at the beginning, Martin, about the sort of the productivity and the developer experience because I think certainly from my perspective, you know, sometimes now there's this conversation that says, you know, oh, nobody needs to care about developer experience because, you know, everybody can just use an LLM to write the code, but we we spend like a fairly small amount of our time actually writing code as developers, I would say.

And we spend much more of our code time reading code. And so this fact that Quarkus has this sort of like really beautiful clean compact syntax for the code that's also really familiar I think is so important even if you know you've got an LLM just sort of spitting out the code because no one wants lots and lots of LLM generated code.

It's just not a good idea. Exactly. Like for sure and like I would just add that Quarkus is one of the frameworks which are pushing LLM integrations in Java.

So like the integration with LLM is so easy that sometimes you will even forget what is calling an LLM and what is actually calling some of your code.

Happened to me. Yeah. Yeah. I know it's very cool. The first time I used that I was just like wow, was it I thought that would be I thought that would be harder.

And very soon there will be a new feature that actually introduces an AI assistant into Quarkus.

So when writing your application itself, you can get assistance that already knows all the internal details about Quarkus.

That's a completely new thing that's coming soon. And obviously, the book doesn't talk about it, but I just wanted to point out that it's coming soon.

>> Yeah. Yeah, it's very cool. So what what inspired you to to write a book?

So, you know, you sort of you like Quarkus and and you have like evenings and weekends free and then you say, "No, no, I I wish to change that." So, I probably will take this one because I kind of forced Jan to go out with me.

>> Actually, it was Heinz Kabutz. You probably know him.

Uh I met him, I don't remember at which conference, and he told me that the thing that he regrets is that he didn't write a book before he was 30.

So I I set a goal for myself that I want to write a book before I was 30, basically.

Then I reached out to some of our internal people at Red Hat and they pointed me to Manning, and by the chance back then somebody was already interested in writing Quarkus in Action, but they dropped for I I don't know the reason and they asked me like, do you want to take Quarkus in Action?

So that's it more or less. Then I reached out to Quarkus's team because I didn't feel confident enough that I can write the book myself, or at least it would take a very long time in my day job.

So Jan volunteered to help and here we are.

Yeah, I think it definitely makes sense to have help, both because things are always better with company, but also because in in something like Quarkus, you know, where it's changing so fast, you know, because you mentioned that that Jan, you know, there's always new stuff coming, and so you need to parallelize in order to be able to get ahead of the the the sort of the the wave of of coming technology.

And you don't know how right you are, because if I remember correctly, we started with the Quarkus version 3.9, if I remember correctly, the first drafts.

>> The first was with Quarkus 2.something, not 3.

>> Okay, so 2.something, I don't even remember. And the final version is 3.15, so you understand 3.15.

1. So you understand how much rewrites and updates we had to do throughout the process. Yeah, you just want your colleagues to just stop working so that you can finish it.

>> And the fun part is that the actual code was easy, because in Quarkus we have this upgrade mechanism with OpenRewrite.

So updating the code is very, very easy, but you have like 300 pages to go through and update all the versions.

>> Yeah. And of course, updating screenshots is no fun.

>> Yeah. >> Yeah. >> Yeah. And any any kind of update of something was actually quite hard.

That's also one of the aspects of working with multiple people working on a book because the they work depends on each other, and when one person decides later on to change something in a previous chapter, then all 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 it it, yeah, it's it's hard.

Yeah. So, so can you sort of talk through, because you hinted at this a bit, about how sort of each each thing builds on the other?

Can you talk through like the structure of the book and what you decided to include and then maybe like as well what you sort of didn't include and and why?

So yeah, let's just like basically skip quickly through the table of contents. So the book is split into three parts.

The the first part is called Getting Started with Quarkus, which is like the introduction, the the motivation why you want to use Quarkus and what the basic principles of it are.

Then within the first part there's this chapter two, uh, that lets you write your first and run your first Quarkus application, where you already get to use the the to see the benefits of dev mode and stuff.

Then in chapter three we show all the goodies, development experience goodies, that that one is really uh, developers will really like chapter 3 because it shows all the developer productivity things.

We will dive into them in a bit, I guess. And then we start, the book starts um, actually developing a a big project.

It's called car rental. It's a sort of microservices that are like a system of managing cars, car fleet for a car rental company.

So with while reading the book, the reader will create this set of microservices. It's like five microservices I think, connected via different kinds of protocols and using different kinds of databases and everything.

In part two of the book, we mostly write these applications, and 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, of course, because we wanted to show just a little bit of everything.

So 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. Then there's a chapter that shows how to develop secure applications, and it's combined with developing front ends with HTMX.

Then there's a chapter about using databases and Hibernate object-relational mapping.

Then there's something about reactive programming and something about reactive messaging. And that concludes part number two.

Part number three is about deploying Quarkus in the cloud. So there we get to containerizing the applications that we created during part two and deploying them in OpenShift.

The last chapter, number 12, is about writing your own extension for Quarkus. If somebody decides to integrate their own framework, then this chapter will give the basic instructions how to do that.

So I would just add to respond to the second part of the question: why we chose what we chose and what we left out.

More than anything, the biggest limitation was the number of pages, because if we would cover like everything in Quarkus, it's now around 850 to 900 extensions.

I'm losing track. It's it's so we basically tried to design a system that was purposely overcomplicating as much as we can really different databases, reactive access, Hibernate Reactive to that matter, no SQL, different HTTP REST, mentioned gRPC, GraphQL.

Basically, already by the end of the book, when you will run all the five services in dev mode, it will run another 12 containers just as the services, which is already kind of hard to run on non not so strong machines.

Yeah. Yeah, that makes sense. Yeah. And makes me laugh about the overcomplicated because I can just imagine that, you know, if it was a real application and, you know, you'd sort of present it to the architecture review board and 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 that's exactly what you want.

So you mentioned that there's like eight or 900 extensions in the ecosystem. I don't know how you would know this unless you'd actually like gone and counted, but do you happen to know like what proportion of those are in the book or like how many extensions are are covered in the book?

I did try to count. I counted by, yeah, I counted by looking at the BOM files and just filtering out all the extension artifact dependencies and I got to 29 declared in the POMs, but it's definitely more because some extensions are brought in transitively.

Yeah, but yeah, we have 29 distinct dependent extension dependency declarations in our palms.

Yeah. So like, yeah, 29 headline features that are covered.

Cool. Definitely the intention was to showcase the use cases for the application development.

We didn't focus on showcasing all the extensions because like definitely there are at least like five databases that we didn't include because we just don't have like the place for that.

Yeah. And so what what section do you think people will be or you know, what what extension or what section do you think people will be most surprised by?

Well, I would say that if for somebody that never touched Quarkus, definitely chapter 3 because that's deep dive into dev mode and that's definitely most interesting feature of all.

But for somebody who is already familiar with that, I would probably say reactive programming because we are kind of stepping back from it and people forget that Quarkus is built on top of Vert.

So you are free to choose if you want to use reactive or just a little bit of reactive which we are also showcasing.

So I think that would be probably the best. I definitely agree with Martin said. I would also add that maybe 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. >> Yeah. And because we like ourselves, we decided to do Kubernetes, OpenShift, and also serverless deployments.

Quarkus in Action • Martin Stefanko, Jan Martiska & Holly Cummins • GOTO 2025

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow and create a better future.

Learn from thought leaders and innovators with top-rated videos released daily, and at our year-round conferences, masterclasses and meetups.

Get started: https://gotopia.tech

GOTO is produced by Trifork, a leading full-service supplier of high-quality, custom-built applications and end-to-end solutions.

GOTO YouTube Channel Code of Conduct: https://blog.gotocon.com/yt-coc


Quarkus in Action • Martin Stefanko, Jan Martiska & Holly Cummins • GOTO 2025

Scripts