スキップしてメイン コンテンツに移動

なぜQuarkusを使うのだろう

開発者仲間に問いかけられて言語化したので、一応記録しておく。

Java界隈だと、王道はSpringで、特にSpringBootはJavaでWeb APIアプリを作るときのデファクト、と言っても過言ではないと思う。
その背景を前提に、なぜあえてQuarkusを選んでいるのか?というのがお題。

とりあえずJavaでの開発経験やコンテナ周りの業務使用経験のあるメンバーで出てきた話や結論としては次の通り。

* SpringBootは便利だが、基礎の枠組みを超えることをする場合にはSpring Frameworkの知識が必要なので、必要となる知識レベルが一定のポイントで急上昇するかも
* Quarkusの場合はFrameworkとしてはもう少し薄いラッパーに近いため、取り入れる各ツールの知識を蓄えれば良さそう
* 最終的にQuarkusでもSpring Bootでもできること自体には大きな差異はなさそう
* JVMで動かすのも良いけど、Nativeにできてとてもつもない高速で起動できるのが強みな気もする
* Spring Frameworkに精通しているメンバーがいたら無理にQuarkusを使用する理由はなさそう
* Spring Frameworkに精通しているメンバーいないならSpring BootよりもQuarkusを使う方が楽な場合もありそう

自分が携わっているプロジェクトではSpring周りの知識に強い人が特別いたわけではないことと、メジャーリリース以前の2019年央頃から好きで自分がQuarkusを推していたことから、Quarkusを使用しているのが現状。
SpringBootをベースにしたプロジェクトで以前に少し辛い思いをしたことも後押しにはなってる。

そもそも使い出したのも、なんか使ってみたら簡単でワクワクしたから、くらいの理由。
でも、今はこれなしでWeb API作るのは結構辛いなあと思う。OpenAPI Generatorと並んで重宝してる。

というわけで、正直突出してQuarkusでなければいけない理由、はないかもしれない、という結論に至った。
一方で、Springに疲れた人たちの十分な代替的選択肢として使えそう、という結論にも至った。

Quarkus採用について、自分はArchitectural Decision Recordを残していなかった。
なぜなら、デザインの対象としてはもっと上位を見ていて、使用するフレームワークのことはそれほど重要な意思決定とみなしていなかったから。
とはいえ、実装レベルのデザインで考えると、当然選択するフレームワークもアーキテクチャー上の決定たりうるので、今後何故この決定をしたのか、をもう少し丁寧に言語化するようにしようと思った。
そうすることで、自分の決定の前提を見つめ直すチャンスができたり、今回のような問いかけによりアクティブに応答ができて議論を深めることができる、そんな気がする。

ちなみに、開発者仲間からは、Red Hatの伊藤ちひろさんの資料はQuarkusを使用していない人には理解がしやすくて良いかも、という話もあがった。
平易だが奇を衒っていなくてわかりやすい資料だと思うので自分としてもおすすめ。