アーキテクチャ移行を俯瞰して、今後どう進展するのかを考えていた。
総合的に見ると、Webのアーキテクチャはネイティブアプリとほぼ同様になり、一部は共用する形態になるだろう。
ただしそれを実現するためには、クライアントサイドに主機能を移し、ネイティブアプリと同様のセッション機構を実装する必要がある。
既存のWebサービスはその過程でMVCフレームワークを捨てることになる。新旧のサービスには連続性がなく、移行プランが立たずに塩漬けになる展開も多いだろう。
フロントエンドの進化
従来のアーキテクチャを破壊的に移行した際、じつは最初の選択を間違えていたのではないかと考えた。
既存資産を捨てるのはコスト面では得ではないからだ。
2020年代のWebのキードライバーは、ブラウザ上でアプリケーションが実用的に動作するようになったことだろう。
これは2015年頃にSPA(Single Page Application)として登場した技術の延長にあるものだ。
SPAにはすでに5年以上の蓄積があるが一般普及しておらず、Webサービスの総数から見れば現状主流とは言いがたい。
登場当初はレンダリング性能が悪く、採用メリットが無かったような印象がある。
Angularでテスト実装を作ったが、動作が緩慢でテスト止まりになった。
フロントエンドについては、この5年で進化したのはハードウェアなのだと思う。
とくにスマートデバイスの処理性能と画面の広さが格段に向上した。
Webの場合は、多種多様なデバイスからアクセス可能であるため、一部のデバイスでしか動作しない機能を投入するとなると、フォールバックの画面が必要になり現実的ではない。
当時のスマートフォンやInternetExplorerをサポートする制約上、SPAを導入できなかったと言える。
ただ、RPG『グランブルーファンタジー』のサービス開始が2014年で、ブラウザ上で巨大なアプリが動作していたから、性能チューニングに手間をかけていれば当初から採用できたのかもしれない。
コアロジックの移動
一方、ソフトウェア・ツールの面では当時からさほど進化しておらず、この点は今後課題となるだろう。
従来のMVCとSPAは両立しない。
SPAを選択しインタラクティブな方向に進化する場合、コアロジックをクライアント側に実装することになる。
クライアントは一般的にJavascriptで書くのだが、Javascriptは品質確保に難がある。
Javascriptのツールやライブラリは細分化され過ぎている。各パッケージのIssueを見ると依存ライブラリの問題の影響を受けているケースが多く、自力で解決できないバグが多々ある。
よってツールの組み合わせが増えるほど、トラブルの難易度が幾何級数的に上がっていく。
中心的な対策は、テストコードの充実になるだろう。
Typescriptのように型機能の対策もあるが、型は実行時エラーや依存ライブラリの問題に無力であり、Javascriptの構造問題にフィットしていない。
ただし、SPA型アーキテクチャはテストコードを書きづらい。サーバーサイドのMVCフレームワークではサーバー単体で主要なテストを完結できるが、コアロジックがクライアントにある場合には、クライアント=サーバーの組み合わせを評価する必要がある。
この点は個々のプロジェクトの地道な努力でカバーするしかないだろう。
サーバーサイドはマイクロサービス化が進む
マイクロサービスもデータの分断という副作用があるため、ここまで普及し切れない技術であった。
しかし、コアロジックがクライアント側に移動することで、データを統合する機能がクライアントに移り、マイクロサービスを利用しやすくなる。
また、マイクロサービスは性能面でスケールさせやすいことも有利に働くだろう。kubernetesがデファクト化したため、コンテナ追加は手軽または自動になる。
サーバーサイドには言語やフレームワークの選択肢が多くあるが、どれを選択するかはマイナーな問題になるだろう。
おそらく主要な関心は相対的にRDBMSに移る。RDBMSはWeb登場から基本的に変わらない技術であり続けているが、今後とも変わらない。
ビューやストアドプロシージャなどの古典的な技術がもう一度注目されるのが妥当と考える。
その先の変数
以上の推定は、ソフトウェアの実行環境としてサーバーとクライアントがあり、クライアントのハード進化が起きたことを前提としている。
この先、サーバー・ハードが格段に進歩した場合には、従来型のアーキテクチャが優勢になる可能性もあり得る。
ただし実際にはサーバーに処理を集約する方式が有利になるほど進化することはないように見ている。
ここまでの経緯を観察していると、とくにRAMのコストパフォーマンス向上が近年止まってきて、これがクライアント重視のトレンドの背景になっているように見える。
容量単価が10分の1程度に下がればサーバー側もより大きな構成をとりやすくなるだろうが、そのような兆候はない。また、多くのVMベースの言語ではRAM消費が大きくなるほどガベージコレクションによる性能劣化の影響を受けやすくなるため、ハードの進化がストレートに効かない可能性も高い。
残る可能性はエッジコンピューティングだろう。エッジコンピューティングは、ソフトウェア・アーキテクチャの観点で見るとレイヤが増えるネックが大きい。
一部の処理をオフロードするような導入形態になると思うが、クライアントまたはサーバーのライブラリに包含されるとすると独立のシナリオとして検討する必要はおそらくない。
クライアントサイドのWebAssemblyについてもこの枠内で整理できるだろう。
総合的に検討すると、冒頭の結論どおりWebアプリもネイティブアプリと同様のアーキテクチャになり、相当の期間安定的な方式になるのではないか。
