Spring BootとPlay Framework、どっちがどう良いの？ 専門家が5つの視点で徹底解説

——Spring BootとPlay Frameworkのベースになっている設計思想や、フレームワークが登場してきた歴史的背景はどのようなものでしょうか？

槙　Spring Bootはそもそも「Spring Framework（以下、Spring）」がベースになっているのでそこからお話しすると、Springの歴史は比較的古くて15年以上前に誕生しました。

もともとはJava 2 Platform, Enterprise Edition（以下、J2EE）¹という仕様に対するアンチテーゼとしてSpringは生まれました。J2EEの仕様では、アプリケーションの設定やコーディングに必要な記述量が多く、開発やテストが大変でした。

ですが、Springが登場したことで、Java開発の世界にDependency Injection（以下、DI）という概念が導入されました。Springが出てきたことでJ2EEと比べて簡潔にJavaのアプリケーションを書けるようになり、テストもしやすくなったんです。

Springのポリシーは誕生当初から「開発者が本来やるべき仕事に集中してもらうこと」で、今も変わりません。ビジネスロジックを書くことに専念してもらって、それ以外の雑多な設定などはフレームワークが担う。こうした流れがずっと続いています。

でも、Springにも途中から課題が生まれてきました。歴史が積み重なるとともに、数多くのサブプロジェクトや機能が生まれましたが、使いこなすにはそれぞれの仕様を理解した上で設定を行う必要が出てきたんです。知り尽くしている人にとっては非常に便利なんですけど、新規でSpringを始める人にとってはハードルが高くなってしまいました。

「イニシャルの学習コストが大きすぎるから改善した方がいい」という議論がSpringの開発コミュニティで行われるようになったんです。

——なるほど。それがSpring Bootに繋がっていくと。

槙　Spring Bootが参考にしたのは、Dropwizardというフレームワークです。

このフレームワークは、アプリケーション開発で必要になる複雑な設定を隠蔽してくれます。かつアプリケーションサーバー不要で、Javaのmainメソッドからアプリケーションを即起動できます。もちろん実行可能なファイルとしてパッケージングも可能です。

「Springもこのような機能を持つべきではないか」という話になり、Spring Bootプロジェクトがスタートしました。複雑だったサブプロジェクトや機能の設定作業が、Spring BootではAutoConfigurationという機能によって自動設定できるようになりました。ソースコード内で特定のライブラリが呼び出されている場合、アプリケーション起動時に必要な設定が暗黙的に用意されるようになったんです。

Springがもともと持っていた思想の通り、「開発者が本来やるべき仕事に集中してもらうこと」が、Spring Bootによってより簡単に実現できるようになりました。

——Springの歴史が垣間見えて面白いですね。Play Frameworkの誕生経緯はどうですか？

高橋　Spring Bootが登場してくる流れと似ているんですが、「Ruby on Railsのような開発スタイルをJavaでもやりたい」というニーズが出てきたんです。どうしても、JavaのWebアプリケーションは開発の手順が複雑になりやすい傾向にあると思います。複雑な設定をしてビルドをして、jarファイルに固めてWebサーバーに乗せてようやく起動、のように。こうした手間を省くべきでは、という文脈が生まれたんです。

もっとシンプルに、開発者がコンパイルという作業を意識せずに、ソースコードを書いて保存したらコンパイル後のファイルが自動的に配置され、ブラウザをリロードしただけで変更後の機能を使えるといい。Webサーバーもフレームワークの機能として組み込まれているといい、と。つまり開発のサイクルを速めたいというニーズが大きくなってきたという背景があります。

先ほどのSpringの話でも出てきましたが、Spring Bootの登場前はSpringを扱うハードルも非常に高かった。そこで、「もっとシンプルに開発できる、攻めた感じのWebフレームワークがあったらいいね」という流れが出てきました。こうした経緯から、独自性の高いフレームワークとしてPlay Frameworkが誕生したんです。

——フレームワークは別のものでも、Spring BootとPlay Frameworkは解決したい課題は一緒だったんですね。

高橋　Play Frameworkには1系と2系がありますが、それぞれの内部実装はかなり異なっています。Play Framework1系の時代はJavaのフレームワークとして使われることが前提だったので、フレームワーク内部のソースコードも主にJavaで書かれていました。

Play Frameworkの機能のなかには、アプリケーションをScalaで開発できるScala Moduleというものが存在していました。過去、Scalaの良質なMVCフレームワークがほとんどなかった時期があり、Scalaに目をつけ始めた人たちがPlay Frameworkに目をつけて、Scalaユーザーが流入しはじめたんです。

その後Play Framework2系の開発が始まりましたが、2系ではなんとフレームワーク内部のソースコードがScalaで書き直されていたんです。要するに2系はScalaのフレームワークとして構築されていて、そこにJavaのAPIを被せることでJavaからも使えるようになっています。

だから、1系の時代に“Javaのフレームワーク”としてPlay Frameworkを使っていた人たちよりも、むしろScalaを好きな人たちが2系を使っているのが現状です。Spring Bootとは完全に住み分けができていますね。

【比較ポイント(2)】得意分野や利用されている領域

——それぞれのフレームワークに「こういう開発スタイルに向いている」という特徴はありますか？

高橋　Springの場合は、昔からあるJavaの流れを踏襲していましたが、Play Frameworkはその流れを汲まずに登場してきたので、Javaの歴史を良い意味で引きずっていないんです。ですから、PHPやRuby on Railsなどで開発をしていた人が、なんらかの理由で移行したい場合にはPlay Frameworkの方が馴染むかもしれません。

Springを使う場合には、そのベースとなっているエコシステムを理解する必要があるので、SpringやJavaの文化にどっぷり浸かる覚悟が必要だと思います。

槙　使用される領域の話をすると、Springは昔からずっとエンタープライズ開発がターゲットでした。だから、エンジニアのコミュニティからはちょっと離れているというか、ユーザーはすごく多いんだけど表に出てこない状況がずっと続いていました。でも、Spring Bootが出て導入のハードルがすごく下がったんです。本当にいろいろな人が使うようになりました。

僕は長年Springをやってきた人間なので、Spring Bootをきっかけにスタートアップ系の企業からエンタープライズ企業まで多くの方々がSpringを使うようになってくれたのは、めちゃくちゃ感慨深いですね。

——Spring Bootの前と後とでは本当に時代が変わったんですね。

【比較ポイント(3)】各コンポーネントの実装スタイル

——フロントエンドやView、Controllerなどの実装スタイルは、それぞれのフレームワークでどのように異なっていますか？

高橋　Play Frameworkはテンプレートエンジンの変遷がけっこう特殊ですね。Play Framework2系からScala Templatesというテンプレートエンジンがバンドルされましたが、このライブラリがPlay Frameworkから切り離されてTwirlという名前になった後、再びPlay Framework内部に戻ってきたんです。

このライブラリでは、テンプレートにHTMLの構文を書くとScalaにコンパイルされます。テンプレート内のパラメータを間違えたりするとコンパイルエラーになるので、その段階で書式の間違いに気づけるんです。Scalaは実行時エラーを嫌うというか、コンパイル段階でエラー検出したいという文化があると感じます。

ただ、テンプレートエンジンはPlay Frameworkのコアの機能ではないので、基本的には「開発者が使いやすいものをなんでも使ってください」というスタンスをとっています。ScalaユーザーはTwirlを用いることが多いですが、例えばJavaユーザーはThymeleafを使ってもいいと思います。Scalaベースのテンプレートエンジンを使うと、追加でScalaを学ぶ必要性が出てくるので。

assetのバンドルまわりについても話すと、Play FrameworkはCoffeeScriptやLESS CSSなどが組み込まれているんですが、これにはPlay Framework2系が出た頃にCoffeeScriptやlessが流行っていたので組み込まれたという歴史的経緯があります。

今はJavaScriptもビルドすることが当たり前になっているので、assetは開発者自身がコンパイルするのがいいと思います。その方が今はスタンダードなやり方かなと。

——Spring Bootは、Viewやフロントエンドまわりはどうでしょうか？

槙　それほど制約はないですが、MVCのアプリケーションでViewを作る場合はThymeleafが使われるケースが圧倒的に多いです。唯一、Spring Bootが公式にアナウンスしているのは「JSPの利用には制約がある」ということです。JSPを使ってしまうと、Spring Bootで実行されるアプリケーションを作る上でさまざまな制約が出てくるからです。

——Controllerの実装方法において、思想の違いはありますか？

高橋　Play FrameworkはControllerに関数型のようなパラダイムを取り入れていて、リクエストを受け付けてResultを返す関数のような設計がされています。1つひとつのルーティングに対してActionが対応するという概念です。

槙　Spring Bootの側は、ベースになっているSpring MVCの拡張性が高いので、Controllerでルーティングに携わる部分はいろいろな書き方ができます。メジャーなのはメソッドにアノテーションを付与する書き方ですが、やろうと思えばRuby on RailsやPlay Frameworkのようにrouteの設定ファイルをつくることも可能なんです。

面白いのは、関数ベースのルーティングもSpring5.0から出てきていることですね。Node.jsのWebアプリケーションフレームワークであるExpress.jsのような書式をイメージしてもらえるといいと思います。

Springでは、伝統的なServletベースであるSpring MVCの他にNettyなどのノンブロッキングなランタイム上でリアクティブプログラミングで記述するSpring WebFluxを選択することもできます。

僕はSpringが大好きなんですけど、その大きな理由はこの例のように登場から15年以上が経ってもプログラミングのさまざまなパラダイムに対応し続けていることです。携わっていて本当に飽きない。すごいフレームワークだなと思いますね。

【比較ポイント(4)】データベース接続まわり

——データベース接続に関する部分はどうでしょうか？

高橋　データベース接続まわりはPlay Frameworkのコア機能には入っていないですね。開発者が自由にライブラリを選べることが大きな特徴だと思います。Play JDBCというAPIが用意されているのでそれに従うことでPlay Framework流の型はできるんですが、使わなければいけない制約は全くありません。ScalaユーザーはScalaのライブラリを自由に使っていいですし、Javaユーザーも同様です。

——コアの部分にデータベース接続系のライブラリを入れていないのは、どういう理由で？

高橋　拡張性を高めるためです。Play Frameworkはもともと、1系から2系へのメジャーアップデートでソースコードが書き直された際に、すごく密結合なつくりになってしまいソースコードの品質に課題がありました。

そこから時代が進むごとにリファクタリングが進んで、1つひとつモジュールが疎結合になっていき拡張性を高めていったんです。その過程でデータベースまわりの実装も分離されていって、「開発者が好きなものを使っていいですよ」という方針になりました。

現在のPlay Frameworkは本当に軽量になっているというか、ControllerのActionハンドリングやDI、アプリケーションのブートストラップまわり、HTTPのハンドリングなど本当にコアとなる機能しか本体には入っていなくて。他機能の選択は、開発者の自由を尊重するというスタイルですね。

——Play Frameworkの思想がよく分かりますね。一方のSpring Bootはどうですか？

槙　冒頭で話したようにSpringには「開発者が本来やるべきことに集中させる」という思想があるので、それがデータベース接続まわりにおいても貫かれています。

例えば、テンプレートパターンが提供されているので、決まり切った煩雑な定型処理を書かなくて済みます。また、リポジトリを定義するだけで利用可能なパターンも用意されており、開発者はインターフェースを作成したりメソッドにアノテーションを付与するだけでCRUD系の冗長な記述（例外処理やコミット、ロールバックなど）を書く必要がなくなり、非常にソースコードをすっきり書けます。

それに、インフラレイヤーをSpringが隠蔽することで、接続先のデータベースがRDBMSでもNoSQL系でも、同じプログラミングモデルで実装できるような機能も提供されています。データベースまわりの品ぞろえは多いですね。

【比較ポイント(5)】今後のリリース展開について

——新機能のリリース予定など、これからの展開はどうでしょうか？

槙　Spring Framework 5.2すなわちSpring Boot 2.2では、起動時のパフォーマンス改善の試みがいくつもなされています。それから、リアクティブ系の機能も今後は充実してきます。リレーショナルデータベース用のリアクティブプログラミングAPIであるR2DBCというプロジェクトがありますが、これをSpringで簡単に使うためのSpring Data R2DBCというプロジェクトも注目です。

加えて、ネットワークレベルでノンブロッキングやバックプレッシャーといったリアクティブアーキテクチャを実現できるRSocketというL7レイヤのプロトコルを、Springで使用可能にする試みもされています。その機能はおそらくSpring5.2で入ってくるので、もうすぐですね。

それと、先ほど言った関数ベースのルーティグフレームワークはこれまではSpring WebFluxでしか利用できませんでしたが、Spring 5.2からはServletランタイム上でも使えるようになる予定です。

Spring WebFluxだとリアクティブプログラミングで記述する必要があり、これまでと異なるパラダイムを学ぶ必要がありましたが、Servletランタイム上であればいつもと同じプログラミングで関数型のメリットを享受できます。

高橋　バックプレッシャーの話が出ましたけど、Play Frameworkはバックプレッシャーに目をつけるのがけっこう早かったですね。Play Framework2.6からバックエンドで使用されるライブラリがAkka HTTPに変わったんですけど、Akka HTTPはバックプレッシャーの仕組みを導入しているライブラリなんです。

——今後、RSocketのプロトコルが使われる場面も増えていきそうですね。Play Frameworkの今後に関してはどうですか？

高橋　Play Frameworkは、2系にメジャーアップデートされた際にコードが丸ごと書き直されて、当時のコードはお世辞にも綺麗とは言えない状態でした。でも、かなりリファクタリングが進んできて、最近リリースされた2.7では相当に整備されてきました。ずっとソースコードをウォッチしている身としては、「本当に綺麗になってきたな」という感慨深さがあります。

機能追加という面では、これからすごい新機能をどんどん増やしていくというよりは、セキュリティまわりを強化したり、HTTP/2対応を行ったりと、現代のWebのトレンドにきちんと追随していくのがフレームワークとしての使命なんじゃないかなと思っています。

それから、Play FrameworkはScalaとの結びつきがかなり強いので、Scalaのバージョンが上がって機能が増えていけばPlay Frameworkにもいいフィードバックがあるでしょう。

今後は、先ほどのバックプレッシャーの話もそうですけれど、開発元のLightbend社がどういう分野に投資していきたいかという方針に応じて、フレームワークとしての進化の方向性も変化してくると思います。

——両フレームワークの専門家であるお2人の言葉、本当に参考になりました。どうもありがとうございました！

取材・執筆：中薗昴　写真：漆原未代