§Play 2の紹介
このページは、2023年10月にリリースされたPlay 3にも適用されます。
2007年以来、私たちはJava Webアプリケーションの開発をより簡単にするために取り組んできました。Playは、Zenexity（後にZengularityとなり、最終的にFabernovelに買収）の内部プロジェクトとして始まり、Webプロジェクトの進め方（開発者の生産性に焦点を当て、Webアーキテクチャを尊重し、最初からパッケージングの慣習に斬新なアプローチを採用すること。つまり、必要に応じていわゆるJEEのベストプラクティスを破ること）に大きな影響を受けました。
2009年、これらのアイデアをオープンソースプロジェクトとしてコミュニティと共有することにしました。直ちに非常に肯定的なフィードバックがあり、プロジェクトは大きな牽引力を得ました。今日、活発な公開開発を長年経て、Playには複数のバージョンがあり、10,000人以上の活発なコミュニティがあり、世界中で本番環境で実行されているアプリケーションの数が増加しています。
プロジェクトを世界に公開することは、確かに多くのフィードバックを得ることを意味しますが、新しいユースケースを発見し、必要な機能について学び、元の設計とその前提で具体的に考慮されていなかったバグを掘り起こすことも意味します。Playをオープンソースプロジェクトとして取り組んできたこれらの年月の間に、私たちはこの種の問題を修正し、より広範なシナリオをサポートするために新しい機能を統合するよう努めてきました。プロジェクトが成長するにつれて、私たちはコミュニティと私たち自身の経験から多くのことを学びました。Playをますます複雑で多様なプロジェクトで使用しています。
一方、テクノロジーとWebは進化し続けています。Webはすべてのアプリケーションの中心となっています。HTML、CSS、JavaScriptのテクノロジーは急速に進化しており、サーバーサイドフレームワークが追いつくことはほぼ不可能です。Webアーキテクチャ全体がリアルタイム処理に向かって急速に進んでおり、今日のプロジェクトプロファイルの新しい要件は、SQLが排他的なデータストアテクノロジーとして機能しなくなったことを意味します。プログラミング言語レベルでは、Scalaを含むいくつかのJVM言語が人気を集め、いくつかの記念碑的な変化を目撃しました。
そのため、私たちは新しい時代のための新しいWebフレームワークであるPlay 2を作成しました。
§非同期プログラミング向けに構築
今日のWebアプリケーションは、より多くの同時リアルタイムデータを統合しているため、Webフレームワークは完全な非同期HTTPプログラミングモデルをサポートする必要があります。当初、私たちはPlayを多くの短命なリクエストを持つ従来のWebアプリケーションを処理するように設計しました。しかし現在、イベントモデルはComet、ロングポーリング、WebSocketを介した永続的な接続の進むべき道です。
Play 2は、すべてのリクエストが潜在的に長寿命であるという前提の下で最初からアーキテクチャ化されています。しかし、それだけではありません。長時間実行されるタスクをスケジュールして実行するための強力な方法も必要です。アクターベースモデルは、高度な並行システムを処理するための今日の最高のモデルであり、JavaとScalaの両方で利用できるそのモデルの最適な実装はAkkaであるため、それを取り入れます。Play 2は、Playアプリケーションに対するネイティブのAkkaサポートを提供し、高度に分散されたシステムを記述できるようにします。
§型安全性に焦点を当てる
Playアプリケーションを記述するために静的に型付けされたプログラミング言語を使用する利点の1つは、コンパイラーがコードの一部をチェックできることです。これは、開発プロセスの早い段階でミスを検出するのに役立つだけでなく、多くの開発者が関わる大規模なプロジェクトに取り組むのもはるかに簡単になります。
Play 2にScalaを追加することで、コンパイラーの保証がさらに強力になることは明らかですが、それだけでは十分ではありません。Play 1.xでは、テンプレートシステムはGroovy言語に基づく動的なものであり、コンパイラーはあまり役に立ちませんでした。その結果、テンプレートのエラーは実行時にのみ検出できました。コントローラーとのグルーコードの検証にも同じことが言えます。
バージョン2.0では、Playがコンパイル時にコードのほとんどをチェックするというアイデアをさらに推進したいと考えていました。そのため、Javaを主要なプログラミング言語として使用している開発者であっても、PlayアプリケーションのデフォルトとしてScalaベースのテンプレートエンジンを使用することにしました。これは、Play 2でテンプレートを記述するためにScalaの専門家になる必要がないという意味ではありません。Play 1.xでテンプレートを記述するためにGroovyを実際に知る必要がなかったのと同じです。
テンプレートでは、Scalaは主にJavaの構文と非常に近い構文で関連情報を表示するためにオブジェクトグラフをナビゲートするために使用されます。ただし、Scalaの力を活用して高度なテンプレート抽象化を記述したい場合は、Scalaが式指向で機能的であり、テンプレートエンジンに最適であることがすぐにわかるでしょう。
これはテンプレートエンジンに当てはまるだけではありません。ルーティングシステムも完全に型チェックされます。Play 2は、ルートの説明をチェックし、リバースルーティング部分を含め、すべてが一貫していることを検証します。
完全にコンパイルされていることの良い副作用は、テンプレートファイルとルートファイルがパッケージ化および再利用しやすくなることです。また、実行時にこれらの部分でパフォーマンスが大幅に向上します。
§JavaとScalaのネイティブサポート
Playプロジェクトの初期段階で、Playアプリケーションの記述にScalaプログラミング言語を使用する可能性を検討し始めました。当初、この作業を外部モジュールとして導入し、フレームワーク自体に影響を与えることなく自由に実験できるようにしました。
JavaベースのフレームワークにScalaを適切に統合することは簡単ではありません。ScalaとJavaの互換性を考慮すると、Scalaの構文をJavaの構文の代わりに使用するだけで、最初に単純な統合をすぐに実現できます。しかし、これは言語を使用する最適な方法ではありません。Scalaは、真のオブジェクト指向と関数型プログラミングを組み合わせたものです。Scalaのすべての機能を活用するには、フレームワークのAPIのほとんどを再考する必要があります。
私たちは、Scalaサポートを個別のモジュールとしてできることの限界にすぐに達しました。Play 1.xで行った最初の設計上の選択（JavaリフレクションAPIとバイトコード操作に大きく依存）により、Playの内部の重要な部分を完全に再考することなく進歩することが困難になりました。一方、新しい型安全なテンプレートエンジンや真新しいSQLアクセスコンポーネントAnormなど、Scalaモジュール用の素晴らしいコンポーネントをいくつか作成しました。そのため、PlayでScalaの力を最大限に引き出すためには、Scalaサポートを個別のモジュールからPlay 2のコアに移行することを決定しました。Play 2は、最初からプログラミング言語としてScalaをネイティブにサポートするように設計されています。
一方、JavaはPlay 2からのサポートが確実に減るわけではありません。むしろ、その逆です。Play 2のビルドにより、Java開発者の開発エクスペリエンスを向上させる機会が得られます。Java開発者は、Javaの特殊性を考慮して記述された実際のJava APIを入手できます。
§強力なビルドシステム
Playプロジェクトの開始当初から、私たちはPlayアプリケーションを実行、コンパイル、デプロイするための新しい方法を選択しました。最初は難解な設計に見えたかもしれませんが、標準のServlet APIの代わりに非同期HTTP APIを提供し、開発中にソースコードのライブコンパイルとリロードを通じて短いフィードバックサイクルを提供し、斬新なパッケージングアプローチを推進することが重要でした。したがって、Playを標準のJEE規則に従わせることは困難でした。
今日、このコンテナレスデプロイメントの考え方は、Javaの世界でますます受け入れられています。これは、HerokuのようなプラットフォームでPlay Frameworkをネイティブに実行できるようにした設計上の選択であり、弾性PaaSプラットフォームでのJavaアプリケーションデプロイメントの将来と考えるモデルを導入しました。
しかし、既存のJavaビルドシステムは、この新しいアプローチをサポートするのに十分な柔軟性がありませんでした。Playアプリケーションを実行およびデプロイするための簡単なツールを提供したかったため、Play 1.xでは、ビルドおよびデプロイメントタスクを処理するためのPythonスクリプトのコレクションを作成しました。
一方、既存の会社のビルドシステムとのビルドプロセスをカスタマイズおよび統合する必要がある、よりエンタープライズ規模のプロジェクトにPlayを使用している開発者は、少し途方に暮れていました。Play 1.xで提供したPythonスクリプトは、完全な機能を備えたビルドシステムではなく、簡単にカスタマイズできません。そのため、Play 2ではより強力なビルドシステムを選択することにしました。
Playの元の規則をサポートするのに十分な柔軟性があり、JavaプロジェクトとScalaプロジェクトをビルドできる最新のビルドツールが必要であるため、sbtをPlay 2に統合することを選択しました。sbtはScalaの事実上のビルドツールであり、Javaコミュニティでもますます受け入れられています。
これは、Mavenプロジェクトとのより優れた統合をすぐに利用でき、プロジェクトを単純なJARファイルのセットとして任意のリポジトリにパッケージ化および公開する機能、特に標準のJavaまたはScalaライブラリプロジェクトであっても、依存するプロジェクトの実行時のライブコンパイルとリロードを意味します。
§データストアとモデルの統合
「データストア」はもはや「SQLデータベース」と同義ではなく、おそらくこれまでもそうではありませんでした。多くの興味深いデータストレージモデルが普及し始めており、さまざまなシナリオに対して異なる特性を提供しています。そのため、PlayのようなWebフレームワークが、開発者が使用するデータストアの種類について大胆な仮定をすることが難しくなっています。Playにおける汎用的なモデルの概念はもはや意味をなさなくなっています。なぜなら、これらのあらゆる種類のテクノロジーを単一のAPIで抽象化することはほぼ不可能だからです。
Play 2では、Webフレームワークとの特別な統合なしに、任意のデータストアドライバ、ORM、またはその他のデータベースアクセスライブラリを非常に簡単に使用できるようにしたいと考えました。私たちは、接続の境界の管理のような一般的な技術的な問題を処理するための最小限のヘルパーを提供したいと考えています。また、特別なニーズのないユーザーのために、従来のデータベースにアクセスするためのデフォルトツールをバンドルすることで、Play Frameworkのフルスタックの側面を維持したいと考えています。それがPlay 2にJPA、Slick、Anormなどのリレーショナルデータベースアクセスライブラリがある理由です。
次へ: Playユーザーグループ
このドキュメントにエラーを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインを読んだ後、お気軽にプルリクエストで貢献してください。質問や共有したいアドバイスはありますか？コミュニティフォーラムでコミュニティとの会話を始めましょう。