WebSocketアプリケーションを作るのにPlay frameworkをつかおう


この記事は、HTML5 Advent Calendar 2012向けに書いています。

HTML5とその周辺技術などを含んでいるアドベントカレンダーということで、WebSocketのバックエンド側の話について書いてみます。 WebSocketはフロントエンド側はおそらくはJavaScript(対応していないブラウザはFlashが橋渡しをするライブラリを使用するかもしれませんが)で書く事になるでしょう。

WebSocketのバックエンド側は、というとNode.jsで書くというのが認識としては広く知られているところではないでしょうか。 しかし、実際WebSocketのサーバーとして機能するものは大量に存在しており、Wikipediaをみただけでも相当数存在することがわかります。

今回は、その中でもオススメなサーバー側フレームワークとしてPlay frameworkを、WebSocketアプリケーション構築のメリット中心に紹介したいと思います。

Play frameworkのサイト

Play frameworkって何ですか?

Play framework(以下Play)は、「一言で言うと、型安全なRails」みたいな形容で表現されることがあります。 Playのバージョンが1の頃は、Javaベースで書かれており、確かにそのような表現がふさわしかったと言えますが、バージョン2以降はScalaで書き直され、それに留まらないようなフレームワークになっていきつつあります。1.xからずっと使ってきたので、2の変化には戸惑いました。 現状、ScalaとJavaで開発が可能な、Webアプリケーションフレームワークとして知られています。

日本では有志による翻訳も行われており、

Play framework 日本語訳サイト

があります。

Playの特徴としては、

  • 全てをコンパイルし、型安全
  • 非同期も同期も得意
  • RESTful的な方向性

が掲げられていますが、

個人的には、

  • Rails以降のMVC型Webアプリケーションフレームワークの作法に則っており、
  • なおかつ、WebSocketとかの非同期系の処理も得意で、
  • 非常に高速に動作し(ただし、コンパイル自体はすこし時間がかかる)、
  • ビルドシステムや本番で使えるWebサーバーがデフォルトで内蔵されていて、
  • 全てがプラガブルな(Play本体自体もビルドシステムのプラグイン)、
  • JavaとScala(とXtend)両方で開発(混ぜられる!!)出来、
  • 静的型付けな言語の魅力を活かしたIDEによる強力な開発サポートを受ける事ができる

という点で気に入っているWebアプリケーションフレームワークです。

Playはよく動作速度に関して、Node.jsと比較されたりします。 両方とも、ノンブロッキングI/O(っていうモデルがあるんです)を採用している点や、WebSocketを扱える点など共通点も多いため、仕方がないのですが、今回は比較はしません。

理由は僕がPlayの魅力のほうを語りたいためと、Node.jsについて語れるほどの知識がないためです。

ということで、WebSocketアプリケーションをPlayで書くメリットについて。

Playおすすめの理由その1

Playは、Webサーバであると同時に、MVCフレームワークである

Playには内蔵サーバーがあり、Playのアプリケーション自体がサーバーとして起動します。これは、テスト用のビルトインサーバーというわけではなく、実際に本番運用も可能な高速なサーバーです。

加えて、Playは、Rails以降のMVC型Webアプリケーションフレームワークと同じように、モデル、ビュー、コントローラーの役割が分かれているタイプのフレームワークで、フォルダ構造もそうなっています。これ系のWebアプリケーションフレームワークをやってきた方なら直感的にどこになにを書くか理解することができるでしょう。

他のフレームワーク同様、テストに関するサポートも手厚く、ユニットテストやファンクショナルテスト、そしてSelenium WebDriverを利用したWebテストが搭載されています。

また、Java版であれば、Ebean ORMによるデータベースアクセス機能、Scala版であればAnorm他様々なデータベースへのアクセス機能が用意されています。

つまり、Playは、従来型のWebアプリケーションを構築する土台として、機能します。

加えて、Playは、WebのサービスにおけるAPIアプリケーションとしても使えるほどの優れたパフォーマンスを発揮します。 例えば、Kloutという世界的に有名なサービスがありますが、これのAPIにPlayが使われていたりします。

Scaling the Klout API with Scala, Akka, and Play « The Official Klout Blog | Klout

そして、重要なのがここからなのですが、これら既にある程度できあがっている作りやすい土台の上に、WebSocketアプリケーションを構築することが出来るのです。

Playおすすめの理由その2

WebSocketとWebアプリケーションの定義がシームレスに行える

ここからは少し実装寄りの話になります。内容としては、Play Javaを例に挙げます。理由はいろいろな事情からPlay Javaが気に入っているからです。 通常Play Javaでは、基本的にはコントローラーのメソッドを1つのURLに割り当てる事が出来ます。 たとえば、こんな風に書きます。

public static Result index() {
    // もろもろの処理を書く
    return ok(index.render());
}

で、これをRoutesの定義ファイルみたいなところに

GET     /index        controllers.Application.index()

こんな風に書くと、「/index」にてアクセスしたときにindex()メソッドが呼ばれるという仕組みになります。 Playではこんな風にルーティングを定義します。 ここまでは、まあだいたいそんな感じだよねってとこかと思います。

続いてWebSocketの場合はどう書くでしょうか。 WebSocketは、フロント側からは独自のプロトコル「ws://」「wss://」でアクセスされます。 コントローラーに書くコードは、下記コードのようになります。

public static WebSocket<JsonNode> websocket() {
  return new WebSocket<JsonNode>() {
    // もろもろの処理を書く
  }
}

さぞや違う書き方かと思えば、ほとんど通常のWebページとおなじだということがわかります。 Result型ではなく、WebSocket<A>型を返すという以外はほぼ同じです。

もちろん「もろもろの処理を書く」の中には、WebSocketで使われる各種メソッドを定義する必要がありますが、定義すればいいものは、開始時に実行されるonReady()、何らかのメッセージを受信した際に実行されるonMessage()、接続を閉じた時に行われるonClose()の3つを定義さえすれば使えます。

これらイベント処理には、Akkaと呼ばれるフレームワークが使われています。

Akkaのサイト

上記コードは、Routesの定義として、

GET     /websocket    controllers.Application.websocket()

こんな風に定義をした上で、ビュー側から

@routes.Application.websocket().webSocketURL(request)

こう呼び出すと、

ws://localhost:9000/websocket

こういうURLとして出力されます。また、wssプロトコルとしてURLを出力したい場合は、

@routes.Application.websocket().webSocketURL(request, true)

と記述すると

wss://localhost:9000/websocket

のようにURLが出力されます。

つまりは、通常のWebアプリケーションを書く感覚でWebSocketアプリが作れちゃうわけです。 加えてフレームワークで使うモデルには当然ダイレクトにアクセスできますし、WebSocketの監視画面なんかもWebSocketとWebアプリケーションを分けて作る場合に比べるとはるかに楽に実装できるであろうことが推測されます。

実はPlay 1.xの頃にもWebSocketは扱えたのですが、WebSocketControllerという専用のコントローラーを使う必要がありました。 その部分もPlay 2.0以降格段に扱いやすくなっています。

是非冬休みにPlay frameworkを試してみてください!

Comments are closed.