§Play 2.5 の新機能
このページでは、Play 2.5 の新機能について説明します。Play 2.5 への移行に必要な変更点については、Play 2.5 移行ガイドを参照してください。
§Akka Streams ベースの新しいストリーミング API
Play 2.5 の主なテーマは、Play のイテレーターベースの非同期 IO API から Akka Streams への移行です。
本質的に、ネットワークを介して通信したり、ファイルシステムにデータの書き込み/読み取りを行うときは、常に何らかのストリーミングが関係します。多くの場合、このストリーミングは低レベルで行われ、フレームワークは実現された値をアプリケーションにインメモリメッセージとして公開します。これは多くの Play アクションの場合であり、ボディパーサーはリクエストボディストリームを解析された JSON オブジェクトなどのオブジェクトに変換し、アプリケーションがそれを消費し、返された結果のボディは、Play がストリームに戻す JSON オブジェクトです。
従来、JVM では、ブロッキング InputStream
および OutputStream
API を使用してストリーミングが行われていました。これらの API は、それらを使用するために専用の thread を必要とします。読み取り時は、その thread はブロックしてデータの到着を待機する必要があり、書き込み時は、その thread はデータのフラッシュを待機してブロックする必要があります。Play のような非同期フレームワークは、このようなブロッキング API を使用しないため、必要なリソースを制限するという多くの利点を提供します。代わりに、ストリーミングには、thread がブロックして待機するのではなく、フレームワークが読み取るデータがあること、またはデータが書き込まれたことを通知される非同期 API を使用する必要があります。
Play 2.5 より前は、Play はこの非同期ストリーミングメカニズムとしてイテレーターを使用していましたが、現在は Akka Streams を使用しています。
§イテレーターではないのはなぜですか?
イテレーターは、非同期ストリーミングを処理するための関数型アプローチです。非常に強力でありながら、非常に小さな API サーフェス領域を提供します。イテレーター API は fold
という 1 つのメソッドで構成されており、残りはすべてこのメソッドの上に構築されたヘルパーです。イテレーターは、コードがコンパイルされる限り、コンカレンシーやエラー処理など、イテレーター自体の実装に関連するバグが発生する可能性は非常に低く、非常に高いレベルの安全性を提供します。ほとんどのバグはイテレーターの「ビジネス」ロジックにあります。
この安全性とシンプルさは素晴らしいものですが、その結果、学習曲線が非常に急峻になります。イテレーターを使用したプログラミングには、従来の IO 処理からの思考の転換が必要であり、多くの開発者は、この転換に必要な投資が、彼らの IO ニーズには高すぎると考えています。イテレーターのもう 1 つの欠点は、高度な関数型プログラミング機能に依存しているため、Java では事実上実装不可能なことです。
§Akka Streams なぜ使うのか
Akka Streams は、安全性、シンプルさ、使いやすさのバランスが優れています。Akka Streams は、正しく実行できることのみができるように意図的に制約していますが、イテレーターほどではありません。概念的には、ほとんどの開発者にとってはるかに使い慣れたものであり、関数型と命令型の両方の方法を提供しています。Akka Streams には、ファーストクラスの Java API もあり、必要な Java のストリーミング要件を簡単に実装できます。
§Akka Streamsはどこで使われるのか?
Play アプリケーションで Akka Streams に出会う場所は次のとおりです。
- フィルター
- ストリーミングレスポンスボディ
- リクエストボディパーサー
- WebSockets
- ストリーミング WS クライアントレスポンス
§リアクティブストリーム
リアクティブストリーム は、非同期ストリーミングのための新しい仕様であり、JDK9 に組み込まれる予定で、JDK6 以上ではスタンドアロンライブラリとして利用できます。一般的に、エンドユーザーライブラリではなく、ストリーミングライブラリがお互いに統合するために実装できる SPI です。Akka Streams とイテレーターの両方で、リアクティブストリーム SPI 実装を提供します。つまり、既存のイテレーターコードは、Play の新しい Akka Streams サポートと簡単に使用できます。また、他のリアクティブストリーム実装も Play で使用できることを意味します。
§イテレーターの将来
イテレーターは、依然として優れたユースケースがいくつかあります。現状では、Play からイテレーターを非推奨にしたり削除したりする計画はありませんが、スタンドアロンライブラリに移行される可能性があります。イテレーターはリアクティブストリームの実装を提供するため、常に Play で使用できます。
§WebSocket フレームのより良い制御
Play 2.5 WebSocket API は、WebSocket フレームを直接制御できます。バイナリ、テキスト、ping、pong、およびクローズフレームを送受信できるようになりました。このレベルの詳細を気にしない場合は、Play は引き続き JSON または XML データを適切な種類のフレームに自動的に変換します。
§新しい Java API
Play 2.5 の Java API は、Scala API と機能的に同等です。これを実現するために、いくつかの新しい Java API を導入しました。
HttpRequestHandler
は、ルーターに送信される前に、受信したリクエストをインターセプトできます。EssentialAction
は、EssentialFilter
とHttpRequestHandler
で使用される低レベルのアクションです。EssentialFilter
/Filter
は、Java でフィルターを作成するために使用します。BodyParser
は、Java でカスタムボディパーサーを作成するために使用します。
§Java 8 クラスを使用するように更新された Java API
2012 年に Play 2.0 がリリースされたとき、Java は Play のスタイルの非同期関数型プログラミングをほとんどサポートしていませんでした。ラムダはなく、Future にはブロッキングインターフェースしかなく、一般的な関数クラスは存在しませんでした。Play は、そのギャップを埋める独自のクラスを提供しました。
Play 2.5 では状況が変わりました。Java 8 は、Play のプログラミングスタイルをはるかに良くサポートするようになりました。Play 2.5 では、Java API が標準の Java 8 クラスを使用するように改良されました。つまり、Play アプリケーションは他の Java ライブラリとの統合が向上し、より慣用的な Java のように見えます。
主な変更点は次のとおりです。
- Java 関数インターフェース (
Runnable
、Consumer
、Predicate
など) を使用します。 (移行ガイドを参照してください。) - Play の
F.Option
の代わりに、Java 8 のOptional
を使用します。 (移行ガイドを参照してください。) - Play の
F.Promise
の代わりに、Java 8 のCompletionStage
を使用します。 (移行ガイドを参照してください。)
§他のロギングフレームワークのサポート
多くのユーザーは独自のロギングフレームワークを使用したいと考えていますが、Play 2.5 までは不可能でした。Play の Logback への固定依存関係が削除され、Play アプリケーションは SLF4J 互換のロギングフレームワークを使用できるようになりました。Logback はデフォルトで含まれていますが、build.sbt
ファイルに設定を含めることで無効にし、独自のフレームワークに置き換えることができます。他のロギングフレームワークを Play で使用する詳細については、Play の ロギングに関するドキュメント を参照してください。
Play アプリケーションは、変更の一環として Play の Logback クラスの 1 つが別のパッケージに移動されたため、構成をわずかに変更する必要があります。詳細については、移行ガイド を参照してください。
§SQL ステートメントのログ記録
Play には、jdbcdslog をベースにした、すべての JDBC データベース、接続プール実装、永続化フレームワーク (Anorm、Ebean、JPA、Slick など) で機能する SQL ステートメントを簡単にログ記録する方法があります。ログを有効にすると、データベースに送信された各 SQL ステートメントと、ステートメントの実行にかかった時間に関するパフォーマンス情報が表示されます。
SQL ロギングの使用方法の詳細については、Play の Java と Scala のデータベースドキュメントを参照してください。
§Netty ネイティブソケットトランスポート
Linux で Play サーバーを実行する場合は、Netty 4.0 で導入された ネイティブソケット機能 を使用することで、パフォーマンスを向上させることができます。
ネイティブソケットを Play で使用する方法については、Netty の構成に関する Play のドキュメントを参照してください。
§パフォーマンスの向上
さまざまなパフォーマンス最適化のおかげで、Play 2.5 のパフォーマンステストフレームワークは、1 秒あたり約 60,000 件のリクエストを示しており、これは **Play 2.4.x よりも約 20% の向上**です。
§WS の改善
Play WSがAsyncHttpClient 2.0にアップグレードされ、リクエストパイプラインフィルター(Scala、Java)が追加されました。これにより、cURL形式でリクエストをログに記録できます。
次へ: 移行ガイド
このドキュメントに誤りを見つけましたか?このページのソースコードはこちらにあります。ドキュメントガイドラインをお読みになった後、プルリクエストを送信していただければ幸いです。ご質問やアドバイスがありましたら、コミュニティフォーラムでコミュニティと会話してください。