はじめに
Quarkus は GraalVM を採用するWebフレームワークとして、フットプリントの軽さの宣伝文句と目新しさで一時注目を浴びた。
確かに Hello World レベルの実装ではボイラー・コードもほとんどなくシンプルで、JVM 上の開発モードでのビルド・ホットデプロイの素早さから、他のWebフレームワークのビルド時間に日々辟易としている Java 開発者の目には魅力的に映った。
しかし実際に開発してみると、コーディングの軽快さを吹き飛ばして余りある問題に遭遇する。
本投稿では、実際に個人開発に採用して直面した Quarkus と GraalVM のメリット・デメリット (主にデメリット) を挙げる。
GraalVM のメリットとデメリット
まず、VM (JVM or GraalVM) の選定について記述する。
GraalVM を使わずして Quarkus を使う意味はあるのか？ との疑問はあるが、GraalVM のメリットは限定的で、引き換えるデメリットは深刻すぎる。GraalVM のメリット・デメリットを理解し、本当に必須の場合のみ GraalVM (そして Quarkus 自体) の採用を判断したい。
GraalVM のメリット
フットプリント
GraalVM 唯一のメリットは、コンテナのバイナリサイズの小ささによるフットプリントの軽さだ。アプリケーションの内容によるが、100ミリ秒未満で起動するとされている。
このメリットが実運用において、一体どのようなユースケースで活きるのだろうか？
GraalVM のデメリット
ビルド時間
GraalVM の第一のデメリットはビルド時間の長さだ。Hello World レベルのアプリでも15分以上と、常用できるレベルではない。そのため開発時は JVM モードでビルド・テストすることになる。
機能制限
第二のデメリットは、Java 標準クラス・機能のいくらかがオミットされていることだ。オミットされた機能・クラスは具体的には公開されず、ポリシーのみ公開 されている。外部ライブラリも含め、GraalVM のオミット機能の利用有無をコードレベルで完全に把握することなど神ならぬ人間には難しい。
ネイティブイメージはロシアンルーレット
開発者は JVM モードでの開発・テストを完了したのち、天に祈りながら GraalVM ビルドの引き金を引く。宣告はコンパイルエラーとなる数分後に下される。無事ビルドが完了しても安心できない。リフレクションでロードされるクラスの欠落はコンパイルでは検知できない。実行時クラスロードに失敗して死ぬ。そして開発者は頭を抱え嘆息し、ライブラリ選定からやり直すのだ。JVM では問題なく動くのに！！
Quarkus のメリットとデメリット
次いで Quarkus 自体のメリット・デメリットを挙げる。
Quarkus のメリット
フットプリント
GraalVM には及ばないが、JVM モードでも Quarkus は Spring や JavaEE に比べ省メモリ・高速起動の利点がある。特に前述のとおり、開発モードでのホットデプロイの素早さは Spring Boot devtools に比べて素早い。
簡潔
Quarkus は Main クラス等ボイラーコードが無く、いきなり REST Resource (Spring での Controller) から記述できる。認証・認可も MP-JWT や KeyCloak の規約に従えば最小限のプロパティとアノテーションのみで実装できる。ORマッパー Panache も最小限の記述で Entity とその CRUD 処理を記述できるよう設計されている (Java としては違和感があるにせよ) 。
Quarkus が他の Java Web フレームワークでなく Ruby や Python 等スクリプト言語を意識していることが伺える。
公式ガイドの充実・わかりやすさ
Spring や JavaEE のドキュメントの読みにくさ、検索性の悪さと比べて Quarkus の公式ガイドは読みやすく、とっつきやすい。サンプルコードも GitHub で公開されている。
当然英語だが Google 翻訳でほぼ問題なく読める。
Quarkus のデメリット
機能の少なさ
ベースとなる MicroProfile 自体がマイクロサービス向けの最小限の仕様であるため、Spring や JavaEE に比べ機能の充実で劣る。外部ライブラリを追加すればコンテナ・メモリサイズが膨れ本末転倒となるし、 GraalVM 採用時は動作不能のリスクを伴う。
画面を SSR とする場合テンプレートは JSP のみでこれも古臭く、あくまでオマケとわかる。パスワード認証も提供されておらず、あくまで REST エンドポイントのためだけの用途に絞るべきである。
情報量・実績
後発のフレームワークを採用する以上、当然のリスク。むしろ自身でナレッジを蓄え、発信する心構え (+ 予算) をもって臨みたい。
反 Oracle
Oracle 用の JDBC ドライバープラグインが提供されていない。
RedHat 社と Oracle 社の対立が影響しているとすれば、将来的にも提供の望みは薄い。
その他
メリット・デメリットとして挙げる程ではないが、Quarkus と付き合う上での前提を記述する。
MicroProfile を理解する
Quarkus は MicroProfile の SmallRye 実装をベースとしている。Quarkus のガイドで不明確・不十分な箇所は MicroProfile のドキュメントを参照すること。
ただし MicroProfile 自体の情報量も少なく、結局最後は「コード読め」となりがち。
RedHat へのロックインを覚悟する
Quarkus は RedHat 社が開発しており、同社製または同社がスポンサーの OSS 製品(KeyCloak、Hibernate)との連携を前提としている。
GraalVM の制約もあるため競合製品の採用は不可能と考え、素直に同社製品を採用することを薦める。
また Quarkus は MicroProfile ベースのため JavaEE のパッケージを多く利用しているが、どこかで JakartaEE に差し替わる覚悟をしておいて損はない。