Build Your Own

CGIが全盛だった頃、フレームワークという概念は黎明期にあった。

GETやPOSTのエンコード処理をCGIの中に記述するのは定型句で作法だった。Content-Typeを判定して、パラメータをデコードして、マルチパートを処理する。毎回同じコードを書く。当然、共通化したくなる。フレームワークを作るしかなかった。選択肢がなかった。

いまのエンジニアが自作のフレームワークを作ることはほぼないだろう。よほど腹をくくった場合以外は。

いつしかhttpdで動くCGIは廃れ、mod_perlになり、httpdすらフレームワークが内包して動くようになった。言語のマルチコア特性が大きな問題になってきたのもこのあたりからだったと思う。プロセスモデルからスレッドモデルへ、そして非同期I/Oへ。フレームワークが面倒を見る範囲は広がり続けた。

自作のフレームワークはいくつも作ってきた。他のフレームワークが出るたびにいいとこ取りしたキメラを作っていたものだ。車輪の再発明と笑われるかもしれないが、車輪の構造を知らずに車を設計するのは怖い。

いまのWebフレームワークは驚くほど多くのことを隠蔽している。ルーティング、ミドルウェア、テンプレートエンジン、ORM、セッション管理。TypeScriptはJavaScriptへのトランスコンパイルを隠蔽し、Next.jsはサーバーとクライアントの境界を隠蔽する。レールの上を走る限り、その下に何があるか知らなくてもアプリケーションは動く。

でもレールから外れた瞬間、隠蔽されていたものが牙を剥く。HTTPの仕様、ソケットの挙動、文字コードの罠、プロセスのライフサイクル。フレームワークが守ってくれていた世界の外は、CGI時代と何も変わっていない。

あの頃キメラを作っていたおかげで、わたしはレールの下を覗くことを怖がらなくなった。いい時代に始めたと思う。もう一度やれと言われたら断るが。