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


GOTO Conferences

Quarkus는 탁월한 개발자 경험을 제공하며, 개발 모드와 지속적인 테스트 같은 기능을 통해 높은 생산성을 보장하고, 이는 'Quarkus in Action' 책에서도 강조됩니다.

Quarkus는 빠른 시작 시간, 낮은 메모리 사용량, 그리고 다양한 프레임워크와 데이터베이스를 아우르는 풍부한 생태계(약 850-900개의 확장 기능)를 통해 마이크로서비스 및 클라우드 네이티브 애플리케이션 개발에 최적화되어 있습니다.

Quarkus는 JVM과 네이티브 컴파일 옵션을 모두 제공하며, 장기 실행 애플리케이션에는 JVM을, 콜드 스타트가 중요한 서버리스나 CLI 도구에는 네이티브 컴파일을 권장하는 등 상황별 최적의 활용 전략을 제시합니다.

Quarkus를 사용하려는 사람들을 위해 이 책을 추천하는 주요 이유와 Quarkus가 제공하는 핵심적인 이점은 무엇인가요?

이 책의 저자들이 Quarkus in Action을 쓰게 된 계기는 무엇이며, 책을 쓰는 과정에서 어떤 어려움이 있었나요?

Quarkus in Action 책의 세 부분은 각각 어떤 내용을 다루고 있으며, '렌터카' 프로젝트는 Quarkus의 어떤 기능들을 보여주기 위해 설계되었나요?

JVM과 네이티브 컴파일 중 어떤 것을 사용해야 하는지에 대한 Quarkus의 권장 사항은 무엇이며, 각 방식의 장단점은 무엇인가요?

이 책을 쓰면서 저자들이 가장 많이 배웠거나 가장 놀랐던 Quarkus의 기능이나 섹션은 무엇이었나요?

안녕하세요, GOTO 북클럽에 오신 것을 환영합니다. 오늘 동료 몇 분과 함께 제가 가장 좋아하는 주제 중 하나인 쿼커스에 대해 이야기하게 되어 정말 기쁩니다.

그래서 우리는 쿼커스 인 액션에 대해 이야기할 것입니다.

이제 소개를 하기 전에, 여러분 모두 책을 가지고 있나요? >> 네.

>> 예. 책 흔들기를 할 수 있습니다. 저는 디지털 버전만 가지고 있어서 책 흔들기를 할 수 없지만, 여러분 두 분은 책 흔들기를 할 수 있습니다.

>> 저희의 사인이 담겨 있습니다. >> 야. 책에 직접 사인하는 건 쉽죠, 그렇죠?

>> 책 내용으로 바로 들어가기 전에, 여러분을 먼저 소개해야 할 것 같습니다.

자신이 누구인지, 어떻게 쿼커스와 관련되게 되었는지 등을 간단하게 소개해주시겠어요?

마틴부터 시작하는 게 좋을 것 같아요.

>> 네, 홀리 감사합니다. 제 이름은 마틴 스테판코입니다. 저는 기본적으로 쿼커스 0.12 버전부터 기여하기 시작했습니다.

이전에는 Wi-Fi 또는 JSOP 애플리케이션 서버에서 약 8년 동안 일했고, 지금은 거의 2년 동안 쿼커스 핵심 팀의 일원으로 여러 확장 기능을 작업하고 있습니다.

>> 안녕하세요, 제 이름은 얀이고, 제 경력은 마틴과 매우 유사합니다.

저도 레드햇 직원으로서 쿼커스에 매우 초기에 기여하기 시작했습니다. 지금은 IBM 직원입니다.

레드햇에서 IBM으로 옮겨졌기 때문입니다. 과거에는 WildFly/JBoss 애플리케이션 서버에서도 작업했습니다. 그래서 네, 매우 유사합니다.

>> 좋습니다. 오늘은 책 내용뿐만 아니라 책을 쓰는 과정에 대해서도 이야기하고 싶습니다. 두 분 모두 첫 책인가요?

맞나요? >> 네. >> 네. >> 네. 정말 크고 흥미로운 일이죠, 그렇죠?

>> 네. >> 책을 쓴 이유에 대해 이야기하기 전에, 사람들이 왜 이 책을 읽고 싶어할지에 대해 생각해 보는 것이 유용할 것 같습니다.

제가 그걸 좀 생각하고 있었는데, 쿼커스를 사용하고 싶어 하는 사람들은 책을 읽고 싶어 할 것이기 때문에 답은 아마도 분명할 거라고 생각했어요.

그러니 어쩌면 두 단계 назад 돌아가서 사람들이 왜 쿼커스를 사용하고 싶어 할까요?

왜 쿼커스가 흥미롭고 신날까요? 물론 당신은 책을 썼으니 신나겠지만, 다른 사람들에게도 왜 그럴까요?

그게 저희가 항상 받는 질문입니다.

아마도 저는 여러 가지 다른 것으로 나눌 것 같아요. 왜냐하면 저는 여전히 엔지니어이기 때문에 쿼커스가 제공하는 개발자 경험이 확실히 중요합니다.

쿼커스의 필수적인 부분인 개발 모드는 책 전체에서 광범위하게 사용하고 있는데, 제 생각에는 제 경력에서 가장 생산적인 도구일 것입니다.

너무 빨라서 제가 동시에 하고 있는 모든 것을 따라잡을 수조차 없어요.

그리고 책 안에서 이걸 많이 보게 될 겁니다. 성능에 대해 이야기하고 싶으신가요?

네, 개발자 경험에 덧붙여서 백그라운드에서 테스트를 실행할 수 있는 지속적인 테스트라는 것도 있습니다.

테스트가 실패하기 전까지는 실행되고 있다는 사실조차 모릅니다. 그리고 네, 더 많은 이유가 있습니다. 네이티브 모드 통합, 빠른 성능, 빌드 시간 초기화 덕분에 매우 빠른 시작 시간과 같은 것들이 있습니다. 빌드 중에 이미 애플리케이션이 부분적으로 초기화되는 자바 세계에서는 매우 혁신적이고 새로운 것입니다.

그리고 실제로 애플리케이션을 시작하면 대부분의 초기화 단계가 이미 완료되었기 때문에 매우 빠릅니다.

그리고 통합의 성장하는 생태계를 가지고 있거나 사람들이 알고 좋아하는 모든 프레임워크를 함께 묶습니다.

그래서 새로운 프레임워크를 많이 배울 필요가 없습니다.

만약 당신이 자바 엔터프라이즈 자바 개발자라면 이미 대부분을 알고 있고 쿼커스는 그것들을 함께 묶었을 뿐입니다.

죄송합니다. 덧붙이자면, 개발 모드를 실행하는 것은 아침에만 할 일이고, 녹색 변화가 빨간색으로 바뀔 때까지 잊어버릴 것이라는 데 전적으로 동의합니다.

그리고 지속적인 테스트, 서비스, UI 등과 같이 많은 기능들이 있습니다. 책에서 별도의 장으로 다루고 있는 이 모든 것들이 개발 모드에 포함되어 있어서 지금 여기서 모든 것을 다 나열할 수는 없습니다.

마틴, 당신이 초반에 생산성과 개발자 경험에 대해 이야기했던 것으로 돌아가고 싶습니다. 제 관점에서 보자면, 요즘에는 '개발자 경험에 신경 쓸 필요가 없다, 왜냐하면 LLM을 사용해서 코드를 작성할 수 있기 때문이다'라는 이야기가 나오지만, 개발자로서 실제로 코드를 작성하는 데는 비교적 적은 시간을 할애한다고 생각합니다.

코드를 읽는 데 훨씬 더 많은 시간을 씁니다. 따라서 Quarkus가 제공하는 정말 아름답고 깔끔하며 간결한 코드 구문은 매우 친숙하기 때문에, LLM이 코드를 쏟아낸다고 해도 매우 중요하다고 생각합니다. 왜냐하면 LLM이 생성한 코드를 많이 원하는 사람은 없기 때문입니다.

정확합니다. 물론이고요. Quarkus는 Java에서 LLM 통합을 추진하는 프레임워크 중 하나입니다.

LLM과의 통합이 너무 쉬워서 때로는 무엇이 LLM을 호출하고 무엇이 실제로 당신의 코드를 호출하는지 잊을 정도입니다.

저도 그랬습니다. 네, 정말 멋집니다. 처음 사용했을 때 '와, 이렇게 쉬울 줄이야'라고 생각했습니다.

그리고 아주 가까운 시일 내에 Quarkus에 AI 어시스턴트를 도입하는 새로운 기능이 추가될 것입니다.

애플리케이션 자체를 작성할 때 Quarkus에 대한 모든 내부 세부 정보를 이미 알고 있는 어시스턴스의 도움을 받을 수 있습니다.

이것은 곧 출시될 완전히 새로운 기능입니다. 물론 책에서는 다루지 않지만 곧 출시될 예정이라는 점을 말씀드리고 싶었습니다.

네, 정말 멋지네요. 책을 쓰게 된 계기가 무엇인가요?

그러니까, 아시다시피, 쿼커스를 좋아하고 저녁과 주말에 시간이 남으면 '안 돼, 안 돼, 그걸 바꿔야겠어.'라고 말하게 되는 거죠. 아마도 제가 얀을 억지로 데리고 나갔기 때문에 제가 이걸 맡게 될 것 같아요.

>> 사실은 하인츠 카부츠였어요. 아마 아실 거예요.

어, 제가 그를 만났는데, 어느 컨퍼런스였는지 기억은 안 나지만, 그가 후회하는 것은 30세 전에 책을 쓰지 않았다는 것이라고 말하더군요.

그래서 저는 30세 전에 책을 쓰고 싶다는 목표를 세웠습니다.

그래서 레드햇 내부 사람들에게 연락했더니 매닝을 소개해 줬고, 우연히도 누군가가 이미 Quarkus in Action을 쓰는 데 관심이 있었지만, 어떤 이유인지 그만두었고, 저에게 Quarkus in Action을 맡아 보겠냐고 물어봤습니다.

대략 그런 내용입니다. 그 후 저는 쿼커스 팀에 연락했는데, 혼자서는 책을 쓸 자신이 없거나, 적어도 제 본업으로는 시간이 너무 오래 걸릴 것 같았기 때문입니다.

그래서 얀이 도와주겠다고 자원했고, 지금 여기에 있습니다.

네, 저는 확실히 도움을 받는 것이 합리적이라고 생각합니다. 동료가 있으면 항상 더 좋기도 하지만, 쿼커스처럼 변화가 매우 빠른 경우에는 얀이 언급했듯이 항상 새로운 것들이 나오기 때문에, 다가오는 기술의 물결에 앞서나가기 위해서는 병렬화해야 합니다.

그리고 당신이 얼마나 옳은지 모를 겁니다. 제가 기억하기로, 처음 초안을 쓸 때 쿼커스 버전 3.9로 시작했습니다.

>> 처음은 쿼커스 2.x 버전이었고, 3이 아니었어요.

>> 아, 2.x 버전이었군요. 기억도 안 나네요. 그리고 최종 버전은 3.15입니다. 3.15를 이해하실 겁니다.

1. 이 과정을 거치면서 얼마나 많은 내용을 다시 쓰고 업데이트해야 했는지 이해하실 겁니다. 네, 그냥 동료들이 일을 그만두고 당신이 끝낼 수 있기를 바랄 뿐이죠.

>> 재밌는 건 쿼커스를 사용하면 OpenRewrite라는 업그레이드 메커니즘이 있어서 실제 코드는 쉽게 작성할 수 있다는 거예요.

그래서 코드 업데이트는 매우 쉽지만, 300페이지 분량을 검토하면서 모든 버전을 업데이트해야 하죠.

>> 네. 물론 스크린샷 업데이트는 재미없죠.

>> 네. >> 네. >> 네. 어떤 종류든 업데이트하는 건 꽤 어려웠어요.

여러 사람이 책을 작업할 때도 마찬가지예요. 작업이 서로에게 영향을 주기 때문에, 한 사람이 이전 챕터의 내용을 나중에 변경하기로 결정하면 모든 내용을 전달하고 다음 챕터를 수정해야 하죠.

다른 사람도 조정을 해야 한다는 뜻인데, 네, 그게 어렵죠.

네. 그래서, 각 요소가 어떻게 서로 연결되는지 조금 설명해 주실 수 있나요? 아까 살짝 언급하셨잖아요.

책의 구조와 포함하기로 결정한 내용, 그리고 포함하지 않기로 한 내용과 그 이유도 설명해 주시겠어요?

네, 그럼 목차를 빠르게 훑어볼게요. 책은 세 부분으로 나뉘어 있어요.

첫 번째 파트는 '쿼커스 시작하기'인데, 쿼커스를 사용하려는 동기와 기본적인 원리를 소개하는 내용이에요.

첫 번째 파트에는 2장이 있는데, 여기서는 첫 번째 쿼커스 애플리케이션을 작성하고 실행하면서 개발 모드의 장점을 직접 경험할 수 있어요.

3장에서는 개발 경험에 도움이 되는 모든 유용한 기능들을 보여주는데, 개발자 생산성을 높여주는 기능들을 소개하기 때문에 개발자들이 정말 좋아할 거예요.

이 부분은 나중에 좀 더 자세히 다룰 것 같아요. 그리고 책에서는 실제로 큰 프로젝트를 개발하기 시작해요.

이 프로젝트는 '렌터카'라고 하는데, 렌터카 회사의 차량 관리를 위한 마이크로서비스 시스템 같은 거예요.

그래서 책을 읽으면서 독자는 이 마이크로서비스 세트를 만들게 돼요. 서로 다른 종류의 프로토콜을 통해 연결되고, 서로 다른 종류의 데이터베이스를 사용하는 5개 정도의 마이크로서비스로 구성되어 있을 거예요.

책 2부에서는 주로 이러한 애플리케이션을 작성하며, 각 장은 사용되는 특정 프레임워크 또는 기술에 중점을 둡니다.

물론 모든 것을 조금씩 보여주고 싶었기 때문에 가능한 모든 프레임워크를 도입하여 시스템을 꽤 복잡하게 만들었습니다.

REST API, REST 클라이언트, GraphQL API, GraphQL 클라이언트, gRPC 서비스, gRPC 클라이언트를 개발하는 방법을 보여줍니다.

그런 다음 테스팅에 대한 장이 나옵니다. 그다음에는 보안 애플리케이션을 개발하는 방법을 보여주는 장이 있고, HTMX로 프런트 엔드를 개발하는 것과 결합되어 있습니다.

그런 다음 데이터베이스와 Hibernate 객체-관계 매핑을 사용하는 방법에 대한 장이 있습니다.

그런 다음 반응형 프로그래밍과 반응형 메시징에 대한 내용이 있습니다. 그리고 그것으로 2부가 끝납니다.

3부는 클라우드에 Quarkus를 배포하는 것에 관한 것입니다. 그래서 2부에서 만든 애플리케이션을 컨테이너화하여 OpenShift에 배포합니다.

마지막 12장은 Quarkus용 확장 프로그램을 직접 작성하는 방법에 대한 것입니다. 누군가가 자신의 프레임워크를 통합하기로 결정했다면 이 장에서 기본적인 방법을 알려줄 것입니다.

질문의 두 번째 부분, 즉 우리가 무엇을 선택하고 무엇을 생략했는지에 대해 답변을 덧붙이고 싶습니다.

무엇보다 가장 큰 제약은 페이지 수였습니다. Quarkus의 모든 것을 다루려면 현재 약 850~900개의 확장 기능이 필요하기 때문입니다.

헷갈리네요. 기본적으로 정말 다양한 데이터베이스, 반응형 액세스, Hibernate Reactive, NoSQL, 다양한 HTTP REST, gRPC, GraphQL을 언급했는데, 최대한 과도하게 복잡한 시스템을 설계하려고 했습니다.

기본적으로 책이 끝날 때쯤 개발 모드에서 5개의 서비스를 모두 실행하면 서비스로만 12개의 컨테이너가 추가로 실행되는데, 이는 성능이 좋지 않은 머신에서는 실행하기가 이미 다소 어렵습니다.

그래서 거기서 잘라야 했습니다.

네, 말이 됩니다. 네. 그리고 과도하게 복잡하다는 말이 웃기네요. 실제 애플리케이션이고 아키텍처 검토 위원회에 제출하면 누군가가 '이것은 CV 중심 개발입니다.'라고 말할 것 같습니다.

이 모든 것을 사용할 필요는 없습니다. 하지만 물론 학습을 위해서는 바로 그런 것을 원합니다.

그래서 생태계에 8, 900개 정도의 확장 기능이 있다고 말씀하셨는데, 실제로 가서 세어보지 않았다면 그걸 어떻게 알 수 있을까요? 책에 얼마나 많은 부분이 포함되어 있는지, 아니면 책에서 다루는 확장 기능이 얼마나 되는지 아시나요?

세어보려고 했었어요. BOM 파일을 보고 모든 확장 기능 아티팩트 종속성을 필터링해서 세어보니 POM에 29개가 선언되어 있었지만, 일부 확장 기능은 전이적으로 가져오기 때문에 훨씬 더 많을 거예요.

네, 저희 팜에는 29개의 개별적인 종속성 확장 기능 선언이 있습니다.

네, 29개의 주요 기능이 다뤄집니다.

좋아요. 애플리케이션 개발에 대한 사용 사례를 보여주는 것이 목적이었습니다.

모든 확장 기능을 보여주는 데 집중하지는 않았어요. 최소 5개 이상의 데이터베이스가 있지만, 그걸 다룰 공간이 없었거든요.

네. 어떤 섹션이 가장 놀라울 거라고 생각하시나요? 어떤 확장 기능이나 섹션이 가장 놀라울 것 같으세요?

Quarkus를 처음 접하는 사람이라면 3장이 가장 흥미로울 거예요. 개발 모드에 대한 심층적인 내용이 담겨 있어서 가장 흥미로운 기능일 겁니다.

하지만 이미 익숙한 사람이라면 반응형 프로그래밍이 가장 놀라울 거예요. 저희는 한발 물러서서 Quarkus가 Vert.x 위에 구축되었다는 사실을 잊고 있거든요.

그래서 반응형을 사용할지, 아니면 저희가 보여주는 것처럼 약간만 사용할지 자유롭게 선택할 수 있습니다.

그게 가장 좋을 것 같아요. 마틴이 말한 것에 전적으로 동의합니다. 클라우드 섹션도 추가하고 싶네요. Quarkus가 실제로 Kubernetes 매니페스트를 생성한다는 사실을 모르는 사람들도 있을 수 있거든요.

그래서 Kubernetes에 배포하기가 매우 쉽습니다. 네. 저희는 저희를 좋아하기 때문에 Kubernetes, OpenShift, 그리고 서버리스 배포도 하기로 했습니다.

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

스크립트