フレームワークに頼りきりだったので、リクエストとレスポンス、アプリケーションの入力と出力などを個別に意識できず、それぞれの責務をうまく分離できていなかった。

リクエスト

ユーザーのアクセスした場所やポストされたパラメーター、自動的に送られるクッキーなどが関心の対象になる。

フレームワークやライブラリによって、参照する方法や保持の形がちがう。

未加工でつっこんだ時の問題

生のリクエストを入力としてそのままアプリケーションに突っ込むような処理にすると単一の環境やその類型の環境でしか動かない。

動かなければそれでいいか、類型の環境で「動いているように見える」と問題が複雑化する。

リクエストをアプリケーションが取りあつかえる形の入力に整形する層は、必ず分離して実装する。

整形された入力からさらに必要なルーティングやフィルタリングを行い、アプリケーションにつっこまれる。

整形はアプリケーションにとってのドメインではないので、その点は留意しておく。

HTTPのページとしてユーザーに結果などを伝えなくてはならない。ステータスコードやクッキー、HTMLが含まれる。

必ずしもアプリケーションの出力がそのまま反映されるとは限らないが、リクエストに対するレスポンスなので、アプリケーションの出力がレスポンスを決定することに間違いはない。

コマンド的なリクエストの場合、アプリケーションは何らかの変更を行って、それの成否のみを返すのみということがある。

この場合、アプリケーションの出力はただの成否なので、それをそのままHTMLに吐き出すということはなく、そこからステータスコードやHTMLを決定する機構が必要になる。

リクエストの扱いと同じく、レスポンスの扱いも環境によってちがう。

クッキー、ステータスコード、ボディなどそれぞれを作成する層と、それをユーザーに返せるように整形する層は分離するべきである。

臨機応変に対応するのがいろいろなバランス取りの問題からも最良だとは思うが、これは分けると決めておいた方が一貫性が保たれるので整理される。

これは本当にまるで意識できてなかったので苦労した。

CGIで動かしたときの立ちあがりの遅さもあるが、そもそもの永続化などインフラ的な準備をどうするか？という視点が全くなかった。

今回特に設定ファイルから自動的にカラムなどが決定される仕組みだったので、本当は初期化がかなりキモで気を遣ってやらなくてはならなかったのではと思った。

最終的に永続化の仕組みはとっぱらってメール送信のみにしたのであまり踏み込めてない。

Sinatraの起動で一緒に初期化、各エントリポイントで出力 = SomeApplication.new(入力).excuteできるような実装にすると分離ができてすっきりできそう。

入力と出力のフォーマットを統一しておけば、リクエストとレスポンスがどうなっても整形層一個つくれば済んでよさそう。

Herokuにポンとのせる、主に静的メインのサイトに、ちょっとしたといあわせとかを処理する小さなアプリケーションを付け加えていくような運用なら使えるのかな。自分で書いてみて特に（運用上は）メリットが見えない。