最近考えているのは、Webアプリケーションフレームワークとの付き合い方とか、移植性の高いWebアプリのアーキテクチャパターンとか、そんなことである。先日公開した flask-skinny はその一環だ。定年まで20年を切ったプログラマ人生の後半戦、まずはこのテーマに自分なりの結論を出したいと思っている。
なぜそんなことを考えているかといえば、これまで勤めてきたいくつかの企業で、フレームワークのアップグレードに追従できなくなっているアプリを見てきたからである。2015年に入社した企業ではRails 2が使われていた。Rails 4がリリースされたのは2013年である。テストコードはなかったから、真面目にアップグレードするとすれば、まずテストコードを書き、Rails 3への移行を試すことになる。当時は他のタスクに追われ、そんな余裕はなかった。2020年の今でも、似たような状況に陥っているWebプログラマは少なくないのではないか。
もういい加減、そんなWebアプリ、そんな負債は生み出したくない。フレームワークのアップグレードに追従しやすい、もしくは別のフレームワークに乗り換えやすい、あるいは他のプログラミング言語に移植しやすい、そういうWebアプリが書きたい。
では、そのためにはどうしたらよいのか。それをプログラマ人生の後半戦の最初のテーマに据えようというわけである。
今のところ、なんとなく考えているのは以下のようなことだ。
-
フルスタックフレームワークは避ける
- いずれ心中することになるから
-
ルーティング処理は自前で書くか、フレームワークに任せる
- ルートをYAMLなりJSONなりで定義し、自前で処理するのが理想的
- とはいえ、移植時にルート定義を書き直すのはそこまで負担にはならなさそう
-
リクエストやレスポンスの抽象化はプログラミング言語かフレームワークに任せる
- WSGIやらRackやらは抽象度が低すぎ、そのまま扱うのは厳しい
- とはいえ、抽象化処理を自前で書くのは車輪の再発明すぎる
- Goの net/http がよさそうに見える
-
データアクセスレイヤへの依存性をビジネスロジックに注入するのはコントローラの役目
- そこまでしてくれるフレームワークはないから
-
ビューテンプレートには Mustache を使う/HTTPレイヤのテストを書く
- いずれも、他の言語に移植しやすくなるから
-
Intent-Responseパターンを活用する
- flask-skinnyで提案したアーキテクチャパターン。詳細は近日公開予定の別記事で
以上のようにまとめてみると、Goなら、超うすうすフレームワークを自前で書けば、移植性の高いWebアプリが書けそうな気がしてきた。フレームワークに必要な機能は下記のみ。
- JSONなりYAMLなりでルートが定義できるルーティング機能
- 外部への依存性(データアクセス、テンプレートエンジン、etc.)をWebアプリに注入できるDI機能
- Intent-ResponseパターンでWebアプリを呼び出す機能
1と2は、いい感じのライブラリがすでにあるかもしれない。3は、flask-skinnyで実現したとおりで、さほど難しいものではない。
というわけで、直近のタスクは上記フレームワークを作ることとなった。Go初学者なので、焦らず進めていく。