リアクティブAPI
Spring Framework 5の大きなテーマの一つであるリアクティブプログラミングに関して、新たな機能が2つ加わっています。
1つ目はリアクティブトランザクションです。リアクティブデータアクセス機能はMongoDBなどのNoSQLデータベースを対象に開発が先行していましたが、昨年から開発が進められているR2DBCによって一部のリレーショナルデータベースでも利用可能になりつつあります。これに合わせ、リアクティブデータアクセスにおいても従来と同様のプログラミングモデルでトランザクション管理を可能にするため、Spring Framework 5.2ではReactiveTransactionManagerというインターフェースが導入されました。Spring Data R2DBC 1.0および Spring Data MongoDB 2.2では、このインターフェースの実装が提供される見込みです。これによって、リアクティブデータアクセスの際にも@Transactionalによる宣言的トランザクションが利用可能になります。
2つ目はRSocketメッセージングです。RSocketとは、Reactive Streamsのバックプレッシャーに対応した新たなL7プロトコルで、1リクエスト-1レスポンス型のインタラクションだけでなく多重・双方向のインタラクションも可能であるという特徴を持ちます。利用シーンとしては例えばマイクロサービスのサービス間通信などが挙げられます。これまでRSocketのAPIを直接利用する方法や、Protocol BuffersによるRPCを利用する方法が提供されていましたが、Spring Framework 5.2からは新たに@MessageMappingアノテーションを使用したSpring Frameworkのメッセージングスタイルでの利用が可能になります。
リアクティブトランザクション、RSocketメッセージングのいずれもSpring Frameworkの一貫したプログラミングモデルと整合するように設計されているようで、従来からのユーザであれば自然にこれらの新しい機能を利用できるでしょう。
Spring Frameworkのリアクティブプログラミングで使用されているReactorのコア機能の改善に関しては2つのツールについて語られていましたので少しだけ紹介します。1つ目は実行時の性能劣化なしでエラー原因の特定を支援するReactor Debug agent、2つ目はブロッキングAPIを使用してしまっている箇所を検出するBlockHoundです。Reactor Debug agentはまだReactorのコア機能として正式に導入されるかは未定のようですが、デバッグの難しさや意図せずブロッキングAPIを使用してしまう問題など、リアクティブプログラミングの利用を阻害する要因を少しでも取り除いていこうという確かな意図が感じられました。
Kotlin、Kofu
Sébastien Deleuzeさんは、キーノートとセッション「Spring Boot with Kotlin, Kofu and Coroutines」で、SpringにおけるKotlin対応やKotlin DSLの「Kofu」に関する新機能と今後のプランを紹介してくれました。
Kotlin対応に関しては、Spring Framework 5.2で追加されたコルーチン用の機能が紹介されました。
コルーチンは中断可能な計算インスタンスです。ユーザレベルスレッドとして実装されることからカーネルレベルスレッドと比較してインスタンス生成コストが安く、主に非同期処理で使われています。Kotlin 1.3から正式にサポートされました。
コルーチンの処理はノンブロッキングであり、同じくノンブロッキングなAPIを提供するReactorと互換性があります。ReactorでMonoを返り値としていたメソッドには、代わりにsuspend修飾子を付与し、Fluxはkotlinx.coroutines.flow.Flowに置き換えることでコルーチンによる実装に変換できます。Flowにもバックプレッシャーが実装されていますが、内部的にはFluxのバックプレッシャーがプッシュ型／プル型のハイブリッドである一方、Flowはコルーチンで実装されたプッシュ型バックプレッシャーであるなどの違いがあります。
Spring Framework 5.2ではコルーチンを利用したリアクティブWebアプリケーションがサポートされます。「Spring Boot with Kotlin, Kofu and Coroutines」では、実際にWebFluxを利用したアプリケーションのControllerとデータベース接続部分を、Reactorによる実装からコルーチンに置き換えるデモを披露してくれました。
今後のKotlin対応としてはSpring Framework 5.3でKotlin 1.4への対応を予定しており、それ以降で対応予定のものとして「Spring Data R2DBC対応」や、「Spring Dataのコルーチンリポジトリのサポート追加」が挙げられていました。
セッション中のデモではKotlinとJavaの実装例の差分を提示しながら両者に大きな差がないことが示されており、Java技術者であればKotlinの学習コストは大きくないというメッセージを感じました。それに加えてJavaと比較してnullセーフなどのメリットがある点も繰り返し強調されていました。セッション全体を通してSébastienさんのKotlinへの熱意を感じることができました。今後もKotlinへの対応がどのように広がりを見せていくのか、注目しておきたいところです。
Kofuについては実験的なプロジェクトであるSpring Fuで開発が進められています。Kofu 0.1では従来のWebFlux.fnに加え、Spring Framework 5.2で導入されるWebMvc.fnやコルーチンスタイルのWebFlux.fnに対応しています。セッションでは、アノテーションを利用して作られたアプリケーションを、コルーチンスタイルのWebFlux.fnに置き換えるデモが披露されました。Kofuのコードベースの設定記法（functional configuration）は、アノテーションによる宣言的なスタイルといずれが良いかは意見が分かれると感じましたが、Beanをプログラマティックに指定する方式は管理面では分かりやすいと感じるプロジェクトもあると感じました。
Kofu 0.2で対応予定の内容として「Spring Security DSL」「Actuator」「Spring Data JDBC、Redis、Cassandra、JOOQ」「GraphQL」を検討中であることを説明してくれました。0.2版までの対応でルーティングやデータベースアクセス、セキュリティといったアプリケーションを作成するための主要スタックが一通り揃うことになるので、正式版となるための山場となるように感じました。0.3版以降の対応としてサーバレスといったキーワードも上がっており、今後の展開にますます目が離せない状況となっています。
