下記の記事で考えていた「移植性の高いWebアプリのアーキテクチャパターン」や「Fat Controllerをコードで防ぐ方法」は、サーバサイドを主に扱ってきた経験に基づくものだ。

ただ、あらためて考えてみれば、サーバサイドでHTMLを組み立てるアーキテクチャパターンそのものが、Webアプリの移植性を低めている元凶なのだろう。気を抜けばビューロジックがコントローラに漏れ出すし、多くの場合テンプレートエンジン依存のビューテンプレートファイルが大量に作られるし、いざ移植したくなったときには、相当な労力が必要になりがちだ。

となれば、サーバサイドをAPIに特化させるのが一案だろう。APIに特化させれば、少なくともサーバサイドにおいては、ビューテンプレートファイルを作らなくてよくなる。

なんだか、汚いものをフロントエンドに押し付けているようで気が引けなくもないが、ちょうどよいことに、昨今ではサーバサイドをAPIに特化させるのが当たり前になってきている。これは、ブラウザ・Android・iOSなど、さまざまなプラットフォームでアプリを提供するのに適しているからだ。

そうなると、今度はフロントエンド側の移植性が気になってくる。たとえば、Nuxt.jsからNext.jsに乗り換えたい、みたいなニーズがあるのかどうか、あるとしたら労力はどのくらいなのか、といったことだ。

そのあたりの感覚はフロントエンドの経験を積まなければわからない。サーバサイドが生んできたいわゆる技術的負債をフロントエンドも生んでいくことになるのか、もうすでに生みまくっているのか、はたまた、優秀なエンジニアたちが日々返済してくれているのか。ぼくが気にすることではないのかもしれないが、でも気になる。

少し探したら下記の記事が見つかった。「強く依存しているライブラリやツールを減らす」といった表現が出てくる。やはりサーバサイドと同じ轍を踏んでいるようだ。とはいえ、あきらめずに返済を進めているのがすばらしい。