SSRでもREST APIが有利になる技術的な場面

Webアーキテクチャ SSR REST API API設計 キャッシュ

SSRではGraphQLよりREST APIが自然に機能する場面がある

最近は「SPA＝GraphQL」「モダン＝GraphQL」という印象が強くなっていますが、SSRでは事情が少し変わります。
SSRでは依然としてREST APIの方が扱いやすく、性能面でも有利になるケースが少なくありません。

これは好みや宗教ではなく、レンダリング方式の違いによるものです。

SSRは「ページ単位」でデータを集めます。
一方GraphQLは「コンポーネント単位」でデータを要求する思想です。
この前提の差が挙動を変えます。

SSRは“ページ生成処理”である

SSRの処理は次の順序になります。

  • HTTPリクエスト受信
  • 必要データを取得
  • HTMLを生成
  • レスポンス返却

つまりSSRでは、レンダリング前に必要な情報がすべて揃っていることが前提になります。

ここで重要なポイントがあります。
SSRでは「画面部品が個別に通信する」ことがありません。

SPAではコンポーネントごとにAPIを呼びますが、SSRではサーバが一括取得します。
この時、REST APIの構造が非常に噛み合います。

REST APIは「まとめて取得」に強い

例えば記事ページを表示するケースを考えます。

必要なデータ：

  • 記事本文
  • 著者
  • コメント一覧
  • 関連記事

RESTなら以下のように取得できます。

GET /articles/10
GET /articles/10/comments
GET /articles/10/related

SSRではこれらをサーバ内部で並列取得し、HTMLに埋め込みます。
ブラウザは1回のレスポンスで完成ページを受け取ります。

GraphQLの場合、1クエリで同じことは可能です。

query {
  article(id:10){
    title
    body
    author { name }
    comments { body }
    related { title }
  }
}

一見GraphQLが優れているように見えます。
しかしSSRでは別の問題が出ます。

SSRとGraphQLで発生しやすいボトルネック

GraphQLの処理は次の流れになります。

  • クエリ解析
  • リゾルバ呼び出し
  • データ解決
  • 結果統合

この「リゾルバ」がSSRと相性の難しい部分です。
コンポーネントごとにデータ解決が発生するため、内部的に多数のDBアクセスが生まれます。

典型例がN+1問題です。

記事1件 → コメント10件 → 投稿者10人

RESTでは1クエリで取得していた情報が、GraphQLでは複数回の問い合わせになる場合があります。
SSRではリクエストごとにこれが発生するため、CPUとDB負荷が増えやすくなります。

キャッシュ戦略が大きく違う

SSRではキャッシュが非常に重要です。
特にCDNキャッシュが効くかどうかが性能を左右します。

REST APIはURL単位でキャッシュできます。

URL キャッシュ
/articles/10 可能
/articles/10/comments 可能

一方GraphQLは通常POSTリクエストです。

POST /graphql

クエリ内容が毎回異なるため、CDNキャッシュが効きません。
結果として毎回アプリケーションサーバまで到達します。

SSRではこの差が大きくなります。
HTMLキャッシュとAPIキャッシュを組み合わせると、RESTの方が構成を単純にできます。

セキュリティ面の違い

REST APIはエンドポイント単位で権限管理できます。

  • /admin/*
  • /public/*

SSRではサーバがAPIを呼ぶため、アクセス制御をサーバ側に集約できます。
GraphQLは単一エンドポイントのため、フィールドレベル認可が必要になります。
実装を誤ると情報漏洩のリスクが増えます。

実務でよく起きる現象

SPAからSSRへ移行するプロジェクトでよく見られるのが、GraphQLサーバの負荷急増です。

理由は単純です。
SPAでは「ユーザー操作時のみ」だったデータ取得が、SSRでは「アクセスのたび」に発生するためです。

つまりSSRは、バックエンドの呼び出し頻度を増やします。
GraphQLの柔軟性が、そのまま負荷増加に直結することがあります。

REST APIが向くSSRのケース

  • 記事サイト
  • ECの商品ページ
  • 公開コンテンツ
  • キャッシュ主体のサービス

これらはページ単位のデータが固定的です。
RESTのURLベース設計と一致します。

逆にGraphQLが向く場合

  • ダッシュボード
  • 個別最適化UI
  • クライアント主導画面

つまりSPA寄りのUIです。

最後に整理すると

RESTとGraphQLの違いは「古い・新しい」ではありません。

REST：リソース取得モデル
GraphQL：問い合わせモデル

SSRはページ生成処理です。
ページという「固定構造」を生成する場合、リソース単位のREST APIが自然に適合します。

GraphQLはコンポーネント駆動のクライアントアプリケーションと相性が良い設計です。
そのため、SSRではREST APIが依然として合理的な選択になる場面が残り続けます。

APIは流行ではなく、レンダリング方式に合わせて選ぶものです。
SSRを採用したとき、GraphQLが最適とは限らない理由はここにあります。