SPAとSSRを混在させるハイブリッド設計法 - Web開発における知見共有系ページ

Webアプリ設計でよくある失敗は「SPAにするか、SSRにするか」を最初に決めてしまうことです。
実務では、この二択自体が誤りです。

現在の大規模Webサービスの多くは、SPAとSSRを同時に使っています。
この構成をハイブリッドレンダリングと呼びます。

結論として、レンダリング方式は「サイト全体」で選ぶものではなく「URL単位」で選びます。
ページの役割ごとに最適な描画方式を割り当てるのが現実的な設計です。

それぞれの特徴を整理します。

公開サイトとアプリケーションを同時に持つサービスでは、どちらか一方では必ず問題が出ます。

例：ECサイト

すべて同じレンダリング方式にすると、どこかが最適化されません。

最も重要なのは「ページの分類」です。

つまり、公開領域とアプリ領域を分離します。

典型的な構成です。

この時点で、1つのアプリではなく「2つのアプリ」が存在します。

実務では次の構造になります。

Frontend Gateway
  ├ Public Renderer（SSR）
  └ App Renderer（SPA）

サーバはリクエストURLを見て振り分けます。

location /mypage/ {
    proxy_pass http://spa_server;
}

location / {
    proxy_pass http://ssr_server;
}

これにより、ユーザーは同じサイトを見ているように感じながら、裏側では描画方式が変わります。

ログイン状態はSPAと相性が良いです。
なぜなら、状態をクライアントで保持できるからです。

localStorage.setItem("token", jwt)

一方、公開ページでこれを行うとキャッシュが効かなくなります。
ここも分離の理由です。

ハイブリッド設計では、データ取得も変わります。

公開ページは「HTMLに含める」、操作画面は「後から取得する」という考え方になります。

初期開発が楽なため、最初は動きます。
しかし後からSEO・OGP・表示速度の問題が発生します。

今度は管理画面が遅くなり、操作性が悪化します。
フォーム入力が多いシステムでは致命的です。

ハイブリッドは強力ですが、設計を誤ると複雑化します。

特に注意すべき点があります。

認証方法を統一しないと、ログインしているのに公開ページで未ログイン扱いになるなどの問題が起きます。

サービスは「サイト」と「アプリ」を同時に持つようになりました。

1つのレンダリング方式では対応できません。
ハイブリッドは妥協ではなく、役割分担です。

SPAとSSRは競合技術ではありません。
役割が違うコンポーネントです。

ページは「表示のためのページ」と「操作のための画面」に分かれます。
レンダリング方式を技術で選ぶのではなく、ページの目的で選ぶと、設計の迷いが減ります。