🧅
Rack & Middleware
Railsの下で動作するHTTP処理レイヤー
RackはRubyのWebサーバー（Puma、Unicorn）とWebフレームワーク（Rails、Sinatra）間の標準インターフェースです。規約は非常にシンプルで、call(env)メソッドが[status, headers, body]配列を返すだけです。
Rails自体も一つのRackアプリです。リクエストが来ると複数のMiddlewareを経由し、最後にRailsルーターに到達します。
主要Middleware（rake middlewareで確認可能）:
ActionDispatch::SSL— HTTPS強制ActionDispatch::Cookies— クッキー処理ActionDispatch::Session— セッション管理ActionDispatch::Flash— フラッシュメッセージRack::MethodOverride— PUT/PATCH/DELETEメソッドサポートActionDispatch::RequestId— リクエスト追跡ID付与
カスタムMiddlewareを作成して、リクエストロギング、認証、CORS処理などをRailsアプリから独立して処理できます。
構造ダイアグラム
リクエストがMiddlewareスタックを通過する過程 (オニオンモデル):
🌐 HTTP Request
↓
Rack::SSL
HTTPS強制
ActionDispatch::Cookies
Cookie処理
ActionDispatch::Session
セッション管理
ActionDispatch::Flash
フラッシュメッセージ
Rack::MethodOverride
PUT/PATCH/DELETEサポート
ActionDispatch::RequestId
リクエスト追跡ID
Rails Router → Controller#Action
↑
レスポンスも逆順でMiddlewareを通過
ポイント: リクエスト/レスポンスが<strong>Middlewareレイヤーを順次通過</strong> — 各レイヤーが独立して処理
キーポイント
1
HTTPリクエストがWebサーバー(Puma)に到着
2
Rackインターフェースを通じてMiddlewareスタックに転送
3
各Middlewareが順番にリクエストを処理/修正（玉ねぎモデル）
4
Rails Routerに到達 → Controller#Action実行
5
レスポンスがMiddlewareスタックを逆順で通過
6
最終レスポンス[status, headers, body]がブラウザに返却
メリット
- ✓ 関心の分離 — Railsコードを触らずに機能追加
- ✓ Ruby Webフレームワーク間互換（Rails、Sinatraなど）
- ✓ テストが容易（独立ユニット）
- ✓ リクエスト/レスポンスパイプラインカスタマイズ
デメリット
- ✗ ミドルウェア順序が重要 — 間違った配置で動作しない
- ✗ デバッグ時どのミドルウェアで問題か見つけにくい
- ✗ 過度なミドルウェアはパフォーマンス低下
- ✗ 抽象化レイヤー追加で複雑度増加
ユースケース
カスタム認証ミドルウェア
APIリクエストロギング
CORS処理
レートリミティング