非フロントエンジニア観点でのMPA・SPA・SSR・SSGの違い

こんにちは。Kaneyasuです。

先日、[すごい広島 IT初心者の会の忘年会](https://pycon-hiroshima.connpass.com/event/304186/)に参加させていただきました。
そこで、「非フロントエンジニア観点でのMPA・SPA・SSR・SSGの違い」というタイトルでLTしました。
本記事はこれをブログにしたものです。

# 本記事のターゲット

本記事はフロントエンドに明るくない方向けに、用語解説をする内容です。
非フロントエンジニア観点なので、ざっくりとした説明になっています。

https://speakerdeck.com/satoshi256kbyte/fei-hurontoensiniaguan-dian-tenompaspassrssgnowei-i

# ざっくりとした比較表

![ざっくりとした比較表](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/ce24cbc6-66c7-efe2-1fc5-19dd924c5db4.png)

# MPA (Multi-Page Application)

![MPA (Multi-Page Application).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/fe90a6d4-4029-c9c8-4b7c-fa79377c0c41.png)

Wordpress、Ruby on Rails、Laravelなど、単独フレームワーク「だけ」でWebシステムを作り切るとこうなりがちです。
画面遷移のたびに全体を再描画する方式です。
ブラウザの挙動で言うと、リンクをクリックして画面遷移する度にブラウザの更新ボタンが×になればこれに該当することが多いです。

MPAそのものに問題があるのではなく、MPAだけで作ると分業がしづらいゆえに、理解不足・体勢の問題が露見しやすいと思っています。
昔よく聞いていた「ブラウザの戻るボタンが効かない（クリックするとエラーになる）」は、GET・POSTの使いわけができてない、URLの設計がまずいなどが原因で、別にMPAが悪いわけではありません。
私のような（元）バックエンドエンジニアがMPAすると、どうしてもDB > バックエンド > フロントエンドという順でやるので、イマドキのWEBシステム開発だとデザインの変更に後手になりがちになると感じています。
これを解消するために、フロントエンドは専門職に任せたいのだけど、MPA「だけ」で組んでるとそれができないのが問題の本質だと思います。

## MPAの通信のイメージ

![MPAの通信のイメージ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/cbfacf1a-c30e-ea64-d12f-ac0cad0040c8.png)

基本、画面遷移のたびに全部取ってくる動きをします。
画像やCSSが画面全体の後に来るのは、画像やCSSのリンクはHTMLに書かれているからです。
HTMLを取得・解析することでブラウザは画像やCSSなどの存在を把握し、それら取りに行くと言う順番になります。

# SPA (Single-Page Application)

![SPA (Single-Page Application).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/60f85264-937a-e422-baa7-9687cfc732c0.png)

対してSPAは、最初に画面を構成する素材一式を一気にクライアントに渡します。
クライアント側は、必要な時に差分のデータを取得して差分データで画面を組み立てて描画します。
これを実現するためにバックエンドとは切り離したフロントエンドだけのフレームワークが存在します。
これらが、React.jsやVue.jsなどです。
SPAを採用すれば、分業は楽になります。
ただし、慣れてない人から見ると独自用語が多く、かなりとっつきにくく難しいと思います。
地域によるかもしれませんが、フロントエンドにフレームワークが存在するという概念自体がピンとこない人もいるのが実情かと思います。

弱点としてはSEO（検索エンジン対策）が弱く、SNSでシェアした時にサムネイルが出ないというのがあります。
検索エンジンはBOTがサイトを回遊することで、サイトを検索結果に反映していきます。
しかし、BOTは画面の差分を作るまではやってくれないため、動的に作られる画面やリンクを辿ってくれないので検索結果に反映されないという具合です。

## SPAの通信のイメージ

![SPAの通信のイメージ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/e56447d7-b5ef-25ab-862e-e53e8336d63d.png)

# SSR (Server-Side Rendering)

![SSR (Server-Side Rendering).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/cfcb8dfa-e497-ea57-c2dc-4992eefd037e.png)

かなり雑な説明ですが、SSRはMPAとSPAの中間の技術です。
画面の一部をサーバー側で組み立てておくことでSPAの弱点を補っています。
SPAにあったメリットも大体享受できます。

一方で、これはサーバー側で処理される、こちらはクライアント側で処理されるという使い分けが発生するため、慣れるまでは結構大変です。
深く考えずに、採用してしまうと、SPAならできたことができない、できそうでできないのような感覚を覚えるかもしれません。
この辺は、React.jsを調べるとすぐNext.jsがHITするので、Next.jsがReact.jsの上位互換・後継のように見えるのが問題なのかなと思います。

# SSG (Static Site Generation)

![SSG (Static Site Generation).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/8366252d-3bd6-0500-d5d6-f774dfb3fdef.png)

SSGは事前にサーバー側で全ページを完全に組み立てておく方式です。
全ページ分のHTMLを完全に作っておいてサーバーに配置しておくことで、クライアントからリクエストされたら静的HTMLを返すだけの状態を作ります。
SSGが全ページ分のHTMLを完全に作っておく工程をビルドと呼びます。
そのまま、コンパイル・ビルドして結果のロードモジュールが全ページ分のHTMLで、それをサーバーに配置しておきますという概念です。

私自身はあくまでシステムの人なので、あまりメリットが理解できていません。
ランディングページなどの短期間でのみ使うサイトだと有用なのだと想像しています。
短期間でのみ使うサイトだとメンテする人もいなくなるので、静的HTMLでサイトを作っておいた方が、放置されてもセキュリティの問題が起きにくいと言うメリットがあるのだと思います。

# まとめ

![ざっくりとした表Part2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/f5f1382f-5163-3153-baca-17c05e0c2b1f.png)

![最後に.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/30f3b547-6d5a-5944-3f66-0c6397ad855d.png)