MS_SinglePageApplication - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Single-page application

概要

特徴

Single-page application（以下、SPA と略す）は、

  • 単一ページで構成される Ajax アプリケーション。

  • HTML5 / CSS や、各種

    を使用することで、

    • UX の向上
    • マルチデバイス対応

    などが可能となる。

処理方式

  • クライアントサイドは各種 JavaScript ライブラリを使用してデータ操作を行い、
  • サーバサイドは WebAPI を使用して RESTful に Action Method を実行する。

サーバー・ステートレス

リッチ・クライアントとしてのフロントエンド

コンポーネント指向

最近の SPA はコンポーネント指向

  • jQuery のように、ページ中の HTML を DOM 処理するような処理は書かない。
  • 横の繋がりも、縦の繋がりも無い（オブジェクト参照的な意味で）。
  • 縦は Binding みたいなことはできる（React の Flux では双方向ではなく単方向）。
  • コンポーネントの切り方が重要になってくる（下手に切ると上手く実装できなくなる）。

補足（この指摘は今も有効）: 「コンポーネントの切り方が重要」は
SPA 開発の本質的な難しさを言い当てている。

単方向データフローでは、状態を持つ位置（どのコンポーネントが真実を持つか）を
誤ると、props のバケツリレーや不整合が発生する。
これに対する現在の定番の答えが次である。

手段 例
状態を上に持ち上げる（Lifting State Up） React の基本形
グローバル ストア Redux / Zustand / Pinia
サーバー状態とクライアント状態を分ける TanStack Query / SWR

特に 3 番目が重要で、
「サーバーから取ってきたデータ」をクライアント状態として抱え込むのをやめ、
キャッシュとして扱うことで、SPA の状態管理は大幅に単純化する。

適合 / 不適合

適合するケース

サーバー・ステートレス

以下のような、リッチ・クライアントとしてのフロントエンド

  • WebAPIをマッシュアップするフロントエンド
  • mBaaS（Resource Server）のフロントエンド
  • サーバーレスのフロントエンド

通信環境

Facebook のようなサービスを

  • 通信回線の品質が低く、
  • 且つ、帯域幅の狭い環境に

配信するケース。

その他の表現

  • みんなが、様々な場所で使うスマホアプリ
  • 項目数が少なめのフロントエンドを高品質に開発（プロダクトの管理画面）

参考

適合しないケース

エントリ系

エントリ系で使えそうで使えないらしい。
（仮想 DOM の機構が有効に機能せずに性能劣化するなど）

エンプラ（SOR）

  • 画面項目の一括の単項目チェックや関連チェックを実装し難い。

    • 特に、コンポーネントなどで分割すると難しくなっていく。
    • これがあったので、Update Panel（部分描画とJavaScript）も
      流行らなかった感がある。

  • イベントのチェーンなどは VB（Windows Forms）でも
    難しくなるので SPA では破綻する。

補足（現在の答え）: 「大量項目の一括バリデーションが書きにくい」
という指摘は、当時の状況としては正しかった。
現在はフォーム ライブラリがこの問題に正面から取り組んでいる。

ライブラリ 特徴
React Hook Form ＋ Zod / Yup スキーマで一括定義。非制御コンポーネントで再描画も抑制
VeeValidate（Vue） 同上
TanStack Form フレームワーク非依存

スキーマ（Zod 等）で定義すれば、相関チェックも宣言的に書け、
同じスキーマをサーバー側でも使い回せる。
「項目数が多いと SPA は破綻する」は、現在では緩和されている。

ただし エントリ系の性能問題（数百項目の再描画）は今も残る論点で、
仮想化（react-window 等）や非制御コンポーネントの選択が必要になる。

問題点

流行りのアーキテクチャであるものの、昨今、色々な問題点が指摘されている。

フレームワークやツール

フレームワークの数、ライフサイクル的な変化が多い

knockout は早々にメインストリームではなくなって、
React、Angular がメインストリームに切り替わっている。
更に最近は、React や Vue が伸びてきているもよう。

補足（その後 10 年の帰結）: 「変化が激しい」という懸念に対して、
現在は主要フレームワークが 3 つに収斂し、状況は落ち着いている。

状況
React 最大シェア。Server Components へ移行中
Vue Vue 3 で安定。Nuxt と併用
Angular 企業系で堅調。Signals 導入で刷新中
Svelte / Solid 小規模・高性能志向で一定の支持
knockout / Backbone 事実上終息

「毎年入れ替わる」時代ではなくなったが、
メジャー バージョン更新のコスト（AngularJS → Angular、Vue 2 → 3）は依然大きい。
SPA を採用する際は、フレームワークの寿命を前提にした更改計画が要る、
という本ページの警戒感自体は今も妥当である。

その中で、１つ１つに、単純な難しさがあるらしい。

ライフサイクルと移行パスに、グレー感がある。

補足: AngularJS（1 系）は 2022 年 1 月にサポート終了した。
Angular（2 系以降）とは実質別物で、移行は書き直しに近い。
ここで懸念されていた「移行パスのグレー感」は、
最終的に「移行パスは無い」という形で決着した。

項目移送の段数が増加する。

方式 段数
ASP.NET Web Forms SQL → DataTable → Binding
ASP.NET MVC SQL → DataTable（or Dapper→ POCO）（→ ViewModel）→ Binding
ASP.NET SPA SQL → DataTable（or Dapper → POCO）→ JSON → ViewModel → Binding
  • ASP.NET Web Forms — 非常にシンプルに書ける。
  • ASP.NET MVC — やり方は数パターンあるが、サボって、
    DataTable を View に持って行くこともできる。
    ただし、サーバサイド技術なので、双方向 Binding は不可。単方向 Binding のみ。
  • ASP.NET SPA — 物理的（クライアント・サーバー）＆
    言語的（.NET・JavaScript）な境界がありサボれない。

補足（この「段数」への現在の対処）: 境界をまたぐたびに
型定義が重複する問題は、スキーマからの自動生成で軽減できる。

手段 内容
OpenAPI からの型生成 Swagger / OpenAPI の定義から TypeScript の型・クライアントを生成（NSwag、openapi-typescript）
gRPC-Web .proto から両側のコードを生成
Blazor C# のまま書き、モデルを共有ライブラリに置く（言語的な境界が消える）

特に最後の点は、Blazor が SPA として選ばれる数少ない
実務的な理由になっている。

参考

Tags: 移行, プログラミング, .NET開発, .NET Core, ASP.NET, ASP.NET SPA, JavaScript

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️