Quarkus を導入するにはいくつか検討すべきことがあります。それらを決定するのに必要な情報をまとめてみました。
考えるべきことは以下の通りです。
- Native Image を導入するか
- Reactive を導入するか
- 依存ライブラリが対応しているか
- Web フロントエンドを何で作るか
Native Image
Quarkus といえば Native Image という印象がありますが、もちろん Native Image じゃない普通の jar としてもビルドできます。 jar でも他のフレームワークと比べると早いので、 Native Image ではなくても Quarkus を導入するメリットは十分にあります。
Native Image を導入するメリットとしては以下があります。
- 起動が早い
- メモリ使用量が少なくなる
デメリットとしては以下です
- ビルドが遅い
- GraalVM の制約があるので設定や調整が必要
注意点は以下です
- 起動後のレスポンスは Native Image でも jar でもそれほど変わらない
正確な数字を計測したいですが、時間が取れないので割愛します。１回雑に計測してみたのですが、公式サイト (ja) に掲載されている数字と同様の結果は出ました。
Native Image は リフレクションやリソースファイルの設定が必要だったり、設定ファイルが足りているかは実行しないと分からないですがビルドに時間がかかるといった具合で、開発に非常に時間がかかります。
ちなみに開発環境が Windows だと Windows の実行ファイル1いわゆる .exeができてしまうのでプロダクション環境と合わせるために Linux でビルドするのですが、 仮想マシン立ち上げてビルドするのでそこそこのマシンスペックが必要です。
Reactive
Quarkus には Reactive と Imperative (classic) という概念があります。Reactive は反応的と訳すようですが、そのままカタカナでリアクティブという表記の方が多い印象です。
対して Imperative は命令型と訳します。従来と同じ方法ということで classic と表記されることもあります。
リアクティブの説明は Quarkus のガイドが分かりやすいです。要約すると、DB 処理などで入出力待ちの間はほかのリクエスト処理した方が効率的だよねといった内容です。
メリットをまとめると以下です。
- DB や REST API などの外部サービス入出力待ちの時間を有効活用できる
デメリットは以下です。
- 既存のコードを Mutiny を使うよう書きなおす必要がある
注意点は以下です。
- Reactive 未対応の拡張がある
簡単に書いてしまいましたがデメリットが非常に大きくて、IO 系のメソッドの戻り値を Mutiny (Uni や Multi) を使って書く必要があります。合わせてメソッドの中身も書き換えるので、移植時のコストが大きくなります。
拡張機能があっても、 Imperative のみ対応という場合があります。例えば quarkus-flyway 2DB マイグレーションツール や quarkus-scheduler などです。
対応する DB にも一部注意が必要です。以下は記事執筆時点での情報ですので、最新の情報は Quarkus のガイド（Reactive, Imperative）からご確認ください。
| DB | Reactive | Imperative |
|---|---|---|
| PostgreSQL | 対応済み | 対応済み |
| MariaDB | 対応済み3MySQL と共通 | 対応済み |
| MySQL | 対応済み | 対応済み |
| SQL Server | プレビュー版 | 対応済み |
| DB2 | プレビュー版 | 対応済み |
| Oracle | プレビュー版 |
依存ライブラリ
Native Image や Reactive を利用するには、依存するライブラリもそれに対応している必要があります。Quarkus のサイトから利用したいものがあるか確認することができます（ここになくても利用できる可能性はあります）。
Quarkus は RedHat が主導していることもあって、依存するライブラリが RedHat に依存しがちです。たとえば JPA は Hibernate になりますし、JAX-RS は RESTEasy といった具合です。といっても RedHat 以上に体力があって OSS に積極的な企業は少ないですし、そもそも他に Reactive に対応している製品を聞いたことがありません。
今後他のものもサポートされるかというとすぐには厳しいと思います。Native Image と Reactive と Imperative すべてに対応するのは非常に手間がかかるためです。もちろん拡張は誰でも作れるので自分で作ることも可能です。
Web フロントエンド
Web アプリを作成する場合は Web ページの出力方法について検討する必要があります。選択肢としては以下です。
- Quarkus で実装する
- Quarkus 以外で作る
Quarkus には Qute というテンプレートエンジンがありますが、がっつり Web アプリを作るにはいくつか不足している機能があります。
- セッションをサポートしていない (2/4 追記: undertow 拡張を使うと
@SessionScopedを使用できるようです) - CSRF 対応がない
REST/GraphQL/gRPC などの API を作るのには優秀ですが、マイクロサービス（ステートレス）用フレームワークということでステートフルな機能の実装が弱いです。
Web アプリは node.js の方がライブラリが充実してますし、 JavaScript や CSS の minify や polyfill をする必要もあるので、 Java で作らず node.js で作ってしまう方がよいと思います。 next.js や nuxt.js がおすすめです。
判断の例
自分が次に個人開発で使用するなら以下のような判断をすると思います。
| 項目 | 判断 | 理由 |
|---|---|---|
| Native Image / jar | jar | Native はビルドが遅すぎて開発する意欲を無くすから。 |
| Reactive / Imperative | Reactive | 移植予定がないため、パフォーマンス重視。DB は postgres。 |
| 依存ライブラリの対応が十分か | 十分 | Hibernate, RESTEasy を使用し、追加で必要なライブラリはないため。 |
| Web フロント | next.js | polyfill や minify のため。 UI のライブラリが node.js のため。 |