Rack(サイト・英語)は、WebサーバとRuby Webサーバフレームワーク間のインターフェイスを提供する。これにより、フレームワークの作成者がそれぞれ特定のWebサーバごとにハンドラーを記述するという負担を軽減し、多くの重複作業をなくす。
Rackでの作業は実に簡単である。以下の例では、Mongrel(source)で実行する最小限のアプリケーションハンドラーを作成するのに必要なことを示している。
require 'rack'
app = lambda { |env| [200, {"Content-Type" => "text/plain"}, ['Hello World!']] }
Rack::Handler::Mongrel.run(app, :Port => 3000)
env引数は、環境変数および要求パラメーターのハッシュ値を含んでいる。ブロックの戻り値は、HTTPステータスコード、ヘッダーおよび応答のボディの3つのエレメントの配列で構成される。
Rackの作成者であるChristian Neukirchen氏が、Rackの変遷についてInfoQに語った。
当初、RubyのWebフレームワークに不満を感じていたので、自分自身で記述する考えをいくつかひねり出した。web.py(サイト・英語)がリリースされ、小さく簡単 に保持できるところが気に入った。そこでフレームワークの記述を始めたが、成果が得られなかった。Cookieの解析などのいつもの記述などをして本筋か らそれてしまったからだ。実際には、他のプロジェクトからコードをコピーしたが、仕上げるまではかなり退屈な作業だった。そんなわけで、そのフレームワー クは決してうまくいかなかった。
その後、Python's Nevow(source)について知り、それと同種のものを実装してみたくなったが、始めるとすぐにサーバごとにヘルパーやアダプタをひたすら書き換え続けていることに 気づいた。Pythonフレームワークについてさらに詳しくなると、WSGI(source)、read、liked、simplifiedそして最終的にdrafted Rackにたどり着いた。すでに記述したコードを再アセンブルし、Python Paste(サイト・英語)の構造に基づいてモジュール方式にした。すると間もなくRack 0.1の準備が整った。
Rackが使用可能だった時、気に入ったフレームワークがなかったので、Coset(source)を実装した。それについてはわたしがこの頃使用しているものである。Camping(source)、web.py(サイト・英語)およびRESTlet(サイト・英語)からインスピレーションを描く。
Rackのサポートをするフレームワークのリスト(サイト・英語)を以下に挙げる。
* Camping(source)(Rackの分配に含まれる)
* Coset(source)
* Halcyon(サイト・英語)
* Maveric(source)
* Merb(サイト・英語)
* Mack(サイト・英語)
* Racktools::SimpleApplication
* Ramaze(サイト・英語)
* Rails(サイト・英語) (第三者、Thinで配送)
* Sinatra(サイト・英語)
* Vintage(サイト・英語)
Rackは、フレームワークと一緒に使用することも可能である。たとえば、ある要求でシンプルかつ高速処理が必要な場合、RackのRack:: Cascadeを使用して複数のアプリケーションをカスケードすることができる。Ezra Zygmuntowicz氏によるブログ記事では、完全にmerbスタックを経由せずに、Rackを使用したファイルのアップロードの方法を紹介してい る(source)。
今後に向けて、Christian氏は1.0リリース仕様の安定化を計画している。
Rackについての詳細は、Rackの公式Webサイト(サイト・英語)を参照のこと。詳細情報に関しては、Rackの内部構造についてまとめたEuruko 07による文書(PDF・英語)が利用可能である。