なんか主語のデカいタイトルの記事だけれど『こういう世界観でWebアプリケーションを開発できたらいいなぁ』と思っていることがあるのでメモしておく。
同時に、これは10年以上前から思っていたことなので現代には合ってないと感じた。思考がWebアプリケーションの進化に追い付いていないのだろうと思う。
何にしてもこれを仕事に応用しようとか考えていなくて、趣味で試している程度の漠然としたものだ。
理想
コードを書いたら動く。他のあらゆる煩わしいことは気にしなくてよい。これが理想だ。
- 唯一の言語、フレームワークで完結する
- コードは静的に検証され、実行すれば期待通りに動く
フロントエンドはこれ、バックエンドはこれ、実行環境はこれ、のように考えどころが多いのは嫌だ。何か1つ覚えればいい状態になりたい。
動かしてみたら動きませんでした、はダルすぎるので書いたら動いてほしい。
一昔前にはSliverlight+ASP.NET、その間のインタフェースはWSDLが一つの理想形だと思っていた。要するに全てをC#で書けて型が付いている状態。自分自身この構成のアプリケーションを開発したことはないので体験が良いかは分からない。体験しない間にSilverlightやWSDLは廃れてしまった。
現代ではBlazorが理想に近い構成であると感じていて、その進化には注目している*1。インタフェースを決めて、それをDIすればいいというのが好みに合ってもいる。
何よりもVisual Studio（Codeじゃないよ）でプロジェクトを開いてF5ボタンを押せばローカルマシンで実行、開発できる。Azure App Serviceにデプロイすればいい感じに本番で動くというシンプルさが良い*2。これと比べるとコンテナベースの開発、運用はまずまずシンプルになっているとは思うけれど、まだまだ考えどころが多いと思う。
C#は『実行すれば期待通りに動く』とまでは言えないだろうから理想には程遠いけれど、現実的にいい塩梅の開発体験はできるのではないかと思っている。
Rustがもっと市民権を得て、.NETくらい書きやすくなると理想に近づいたりするのだろうか？ その辺は極々表層的なところしか知らない。
現実とのギャップ
この理想はモノリシックなWebアプリケーションであることが前提で、ある程度以上の開発規模への適応は難しいだろうなと思う。
要するに開発チームが分かれたらみたいな話。チームが分かれたら1つに統一されているメリットはなくなって、個別に最適化できないデメリットだけが残る。
適当に責務の境界になるインタフェースを設けて分担していけばいいのだろうけれど、それはもう次元が違う世界の話で手に負えない。
現実への落としどころ
フロントエンドはこれ、バックエンドはこれ、実行環境はこれ、のように考えどころが多いのは嫌だ。何か1つ覚えればいい状態になりたい。
理想的なマイクロサービスでは『このチームはこれを開発する』が綺麗に分けられていて、何か1つ覚えればいいになるのだろうけれど、それができている組織がどのくらい存在するのだろうか？
超大手Webサービスが無尽蔵にあるリソースで運用している『こうするとよい！』はそりゃぁいいのだろうけれど、それを適用できる、適用するといい場面はさほど多くないだろう。
身の丈に合ったアーキテクチャで開発運用するのが大事だと思っている。
もしかしたら先に書いた理想がハマる場面があるのかもしれない。というか、Blazorを採用したい場面ってそういう場面だよなと思う。
現実に落とし込んでる事例を見てみたいもんだ。
ド現実
んで現実の仕事でどうしてるのかというと、この記事では全然全くこれっぽちも触れていない感じの構成でやっている。
それもまたよし。
そのうち僕なりチームメンバーなりが発信できるといいなとは思っている。
個人的には『あるチームがこういう背景でこんな風に現実と付き合っています』って内容を共有したいのだけれど、そういう指向を持ち込みたかったらお前が発信しろって話だな。
機会と余裕*3があればまとめたいもんだ。
