# SSR vs SPA

## SSR

**SSR(Server Side Rendering)**では、HTTPリクエストをもとに文字通りサーバ側で描画を行います。この方式には以下のようなメリット・デメリットがあります。

### メリット

* SPAの場合はページの描画完了までの速度は **利用者側の端末(例: スマートフォン・ラップトップ)の性能**に大きく依存するが、SSRはサーバ内で完結するので制御できる（= 性能の高いサーバを用意すれば描画速度を改善できる余地がある）
* SPAと比べてコンテンツの生成はサーバ側(限られた開発者しかアクセス出来ない環境)で行われるため、**セキュリティの面で有利**。(= 改ざんされづらい)

### デメリット

* **サーバ側で描画する = SPAと比べてサーバに負荷が掛かる**ので、アクセス数が多い場合にはそれなりの性能のサーバを用意する必要がある。実際には[CDN](https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%83%87%E3%83%AA%E3%83%90%E3%83%AA%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF)を用いた[キャッシュ](https://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5_\(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0\))を行うことで、サーバに負荷が掛からないように対処する事がある。(キャッシュをするとキャッシュの破棄の問題も出てくるので、そちらにも対応が必要)

## SPA

**SPA(Single Page Application)**では、ブラウザ側でHTMLの初期描画を行ったうえで、AJAXを用いて後追いでデータを取得し、その内容を元にページのコンテンツの描画を行います。この方式には以下のようなメリット・デメリットがあります。

### メリット

* SSRと比べてブラウザ側での処理が多いため、**サーバ側の負荷が軽く済む**(言い換えるとクライアント側の負荷が重くなるデメリットでもある)。とはいえスマートフォン・ラップトップともに昔の端末と比べて性能が大きく向上しているため、問題になることは少ない。
* サーバ側はAPIサーバとしてJSONを返却する事に専念できるので、実装がシンプルになる。また**ネイティブ(モバイル)アプリを開発する際にもAPIサーバは再利用できる。**(SSRの場合は、別途APIサーバを作る必要が出てくる。)

### デメリット

* 初期のHTTPレスポンスには返却すべきHTMLコンテンツがまだ含まれてないため、**一部のクローラ(例: Facebook・TwitterのOGP / Google)がコンテンツの解釈をうまく出来ない場合がある。**その場合は**SSRと一部併用する**(= JAM Stackと呼ばれる構成)か、Pre-renderと呼ばれる事前描画の仕組みを利用して解決したりする。Googleのクローラに関してはある程度JavaScriptによるコンテンツの変更も解釈出来るようになってきているので、全く動かないという事はないものの。仕組みに関しては理解しておきましょう。
* フロント(ブラウザ)側で描画する。という仕組みである以上、**サーバ側(通常は開発者が関しできるリソース)と比べて信頼が置けない環境で実行されます**。例えば悪意のある人がソースコードを差し替えて実行できる(例: バリデーションのコードをスキップできる)ので、クライアント側での妥当性(バリデーション)のチェックは**セキュリティの観点では**意味がない。ということを覚えておいてください。

## まとめ

プロジェクトの要件に合わせて適切な構成を選びましょう。不向きな構成(例: OGP対応が必要なサイトをSPAとして作る)をあえてやる場合は、適切な対処が必要なことを覚えておいてください。

* ECサイトはSSRで作る = セキュリティの面で問題が出ないように対処しやすい
* ネイティブアプリに似せた動き(アニメーション)の多いページはSPAで作る = SSRの場合よりも制御できる範囲が広い(例: **ページ間のトランジション**を実装できる)