ScalaのWebフレームワーク事情 2015年版

ScalaのWebフレームワークについて、昨年某所で書いた記事をアップデートしてみました。マイクロサービスが流行ってきたり、Playは2.4になっていろいろ変わったり、ScalaのライブラリやフレームワークもFutureやモナドを活用したものが増えてきたり等々、この一年でScala界隈のWeb開発事情もいろいろと変化してきています。

Play2

出たばかりの頃はPlay 1.x系でできたことができなかったり、バグだらけだったりでコミュニティでも暴動が起きそうになったものですが、喉元すぎればなんとやら、いまでも使いにくい部分も多いのですが、Typesafe社のお墨付きということもあり、なんだかんだでデファクトスタンダードの位置を確立しているのではないかと思います。

ユーザ数が多いだけあり、プラグインや周辺ライブラリ、Web上での情報等も豊富です。

ただ、Play 2.4でGuiceを使ったDIが導入されるなど、まだまだドラスティックな変更が行われています。個人的にはScalaでDIって要るのかなぁと思わなくもないのですが、Railsを見てもわかるように変化し続けることもひとつの価値だと思いますのでアクティブに開発されているという面は評価すべきかと思います。

足回りがNettyなので、政治的な理由でJavaEEサーバの導入が決定しているようなケースでは導入が難しいという点が難点と言えるかもしれません。

Scalatra

自分がコミッタだからというわけではないのですが、個人的にはサーブレットコンテナ上で動作するWebアプリケーションを開発するのであれば一推しのフレームワークです。

名前からもわかる通り、RubySinatra風のフレームワークで、使いやすく、安定しており、拡張もしやすいです。サーブレットAPIを使うこともできるという安心感もあります。GitBucketもこのScalatraを使って作られています。

ただ、サーブレットベースということもあり、ノンブロッキングI/Oを活用したFutureベースのライブラリやフレームワークと組み合わせづらいという問題があります。また、抱えているプロダクトに対して開発リソースが不足気味で(自分もあまり貢献できていないのですが…)、開発速度はあまり速いとは言えません。

Skinny Framework

エムスリーの瀬良さんを中心に開発されているフルスタックのWebフレームワークで、Scalatraをベースにしています。

Scalatraを使う場合はバリデーションやORMなど様々な機能を別途組み合わせて使う必要があるのですが、そういったものが予めセットになっているのは嬉しい点です。Play(の一部)やSlickは関数型っぽい部分に敷居の高さがありますが、SkinnyはORM含めてScalaの良さは出しつつも扱いやすいインターフェースになっているのでScala初心者でも入りやすいのではないかと思います。

また、国産ではありますがドキュメントは英語で書かれているなど海外のユーザにも広く使って欲しいという意図を強く感じます。とはいえ開発者が身近な日本人であり、日本語情報を得やすかったり日本語でのフィードバックを行いやすかったりといった点がメリットになるケースも多いのではないかと思います。

なお、ScalatraをフォークしたSkinny Microというマイクロフレームワークも存在します。シンプルなWebアプリケーションやAPIサーバといった用途であればこちらを選ぶのもありかもしれません。

Lift

Scalaの初期の頃に登場し注目されたフレームワークですが、わすれていいと思いますw

ビュー駆動という発想は新しくて良かったと思うのですが、アプリケーションの設計に独自の思想が必要だったこと、世の中がRESTの方向に行ってしまいビュー駆動というアプローチ自体にそれほど必要性が感じられなくなってしまったことなどがいまいち流行らなかった理由として挙げられます。

懸念事項としてはPlay2と比べても開発方針がアグレッシブで、過去のバージョンを置き去りにする傾向があるということでしょうか(開発リソースが不足していて過去のバージョンをメンテできていないのかもしれませんが)。

まとめ

今のところPlay2がScalaによるWebアプリケーションフレームワークの標準といっていいと思います。少なくとも将来性等も含め、特に縛りがなければ取り敢えずPlayを選んでおけば間違いない、というレベルには達しているのではないでしょうか。

ただ、サーブレットコンテナ上で動かしたい事情があるのであればScalatra、かつフルスタックフレームワークが必要であればSkinny Frameworkが選択肢になるでしょうし、Webアプリケーションではなく完全なAPIサーバであればここで紹介したフレームワーク以外にもFinagleなども候補に入ってきます。

Play2がデファクトとはいえまだ完全にこれ一択という状況ではなく、用途やチームの状況等に応じて適切なフレームワークを選ぶとよいのではないかと思います。