# MVC SPA SSR

基本語法跟原生的 ASP（Java Server Pages）、PHP 有點像，藉由 <% & %> 標出 Java 程式的範圍，後端進行編譯、運算後，再將處理好的 .jsp 檔回給前端；而與使用者的的互動則透過 jQuery 控制。因此那時所撰寫的程式經常會在同一隻 .jsp 檔，內容混合著 Java 及 JavaScript 的程式，再加上透過 jQuery 動態操縱 DOM 及 CSS，可以說是真正的 **義大利麵程式碼**。

### MVC

因為開發者就開始嘗試，將資料與UI分離

先去Model拿資料，把資料塞入View，[連接角色]叫Controller

MVC就是因為code變得越來越亂，所以將職責分清楚的一種設計模式。SPA就是因為想增進使用者體驗，而出現的一種前端利用Ajax(Asynchronous Javascript and XML)達成不換頁的方法。SSR就是因為要解決SPA的SEO問題而出現的解法。

### SPA前後端分離流程

1. 使用者造訪 /posts 這個網址，代表他想看全部文章
2. 前端的路由去處理，負責呼叫對應到的 controller
3. 前端 controller 去呼叫 Model 拿資料
4. 前端 Model 透過 API，去 /api/posts 這個網址拿資料
5. 後端路由接到 request，丟給對應到的後端 controller
6. 後端 controller 跟後端 Model 拿資料
7. 後端 controller 把資料傳回去
8. 前端 Modle 拿到資料以後回傳給前端 controller，並且把資料丟給 view
9. client side render，把畫面渲染出來

以上整套流程就是最基本的SPA架構了，後端只負責輸出資料，前端來負責抓資料跟渲染畫面，把前後端完成切開後，就算後端壞掉，前端還是看得到畫面(只是可能會顯個錯誤畫面)，前端壞掉，後端還是能安穩的輸出資料供其他服務使用。

### SPA的需要

像是**音樂播放網站**，因為必須一邊播放音樂，一邊可以在網站上看其他資料，如果今天不是用SPA，那使用者點到別的頁面時，瀏覽器跳頁，因為就會停止，這使用者體驗就會很差。

所以這種網站就一定要用SPA，當你點擊歌手介紹時，只是發一個ajax request，然後收到response之後用JavaScript把接收到的資料render成HTML顯示出來。

#### Client-Side-Rendering (CSR)
Server (response) => Browser(下載js) => 畫面和互動

> 是瀏覽器載入 JS 後再去執行它，最後靠 JS 才能渲染出要顯示的元件與交互
> 那些元素原本不存在 index.html 裡面，是我們後來自己用 jQuery append 上去的，所以檢視原始碼當然不會出現任何東西。
:::warning
#### SEO問題
要解決 SEO 的問題，通常會採用 pre-rendering 的方式，所謂 pre-rendering 一般來說是指在送到 client 端以前就把 HTML 渲染出來，常見的 pre-rendering 有兩種方式：
* Static Site Generation (SSG)
* Server Side Rendering (SSR)
:::

#### Static Site Generation (SSG)
Server (response) => Browser(下載js、畫面) => 互動
> 意指 HTML 在 build time 時就由 server 產生好，並且在之後的 client request 都會共用這個 HTML。採用這種方式的優點為效能方面，因為它有較好的快取機制，不過它的限制也十分明顯，因為頁面資料的抓取（如 API call）**只能透過 application build** 的時候，因此比較適合使用在內容不需要經常變換的頁面上

#### Server Side Rendering (SSR)
> 沒想到到這裡才要來介紹本篇的主角 SSR，SSR 與 SSG ㄧ樣都是在 server 先建立好要回傳的 HTML 內容，然而不同的是 SSR 在對該頁面的每一個 request 都會重新抓取，也就是說它是與 SSG 的 static 相對應的 dynamic 形式。每當有 client 發起對某個頁面的 request 時，server 會抓取對應的資料，建立完整的 HTML，最後再回傳給 client。

### SPA缺點

例如明明只要看一個頁面而已，卻要把一大包的JavaScript或是其他頁面的template一起下載下來，又或是因為是 client side render，所以有些搜尋引擎爬不到任何資料(因為index.html幾乎是空的)，不過Google會爬JavaScript執行完的結果，可是對於其他瀏覽器就不一定會支援，且這對SEO來說還是不太好。

上面都有一些解決辦法，例如說把js檔案分開，你到那一個頁面就只要下載那一個頁面的js即可，SEO的解決方法則是將兩總結合，第一次先在sever side render，之後的操作都改用client side render，就可以保證搜尋引擎也能爬到完整的HTML。

### 前端的SPA

SPA問題只在第一畫面，由於需要仰賴前端下載大量 JavaScript 檔案，隨後才計算、渲染畫面，那就先在伺服器先算好第一畫面，其他畫面再透過JS動態處理;也就是第一畫面是SSR，其他畫面是CSR
代價就是同一頁畫面需要實作兩次顯示邏輯(前後端各一次)，幸好 JavaScript 不是一個純粹前端的語言，後端可以跑在 Node.js 中，開發者得以使用大致相同的程式，實現這樣的需求；這種同一份 JavaScript Code 可以跑在前端與後端的程式設計，叫做 Isomorphic JavaScript，同構的 JS。
也有人叫做 Universal JavaScript，通用的 JS。
在這樣的概念出來後，前端框架的 SSR 框架也就應運而生了，例如 React 的 Next，及 Vue 的 Nuxt，都是原本前端框架的語法再擴充，讓原先就熟悉框架的開發者，只需要越過相對小的進入門檻，就能滿足第一頁 SSR 的需求。

參考資料：
[跟著小明一起搞懂技術名詞：MVC、SPA 與 SSR](https://hulitw.medium.com/introduction-mvc-spa-and-ssr-545c941669e9#:~:text=%E5%A6%82%E6%AD%A4%E4%B8%80%E4%BE%86%EF%BC%8C%E4%BD%BF%E7%94%A8%E8%80%85,%E6%98%AFMPA%EF%BC%8CMultiple%20Page%20Application%E3%80%82)
[前後端分離與 SPA](https://blog.techbridge.cc/2017/09/16/frontend-backend-mvc/)
[前端三十｜18. [FE] 為什麼網站要做成 SPA？SSR 的優點是什麼？](https://medium.com/schaoss-blog/%E5%89%8D%E7%AB%AF%E4%B8%89%E5%8D%81-18-fe-%E7%82%BA%E4%BB%80%E9%BA%BC%E7%B6%B2%E7%AB%99%E8%A6%81%E5%81%9A%E6%88%90-spa-ssr-%E7%9A%84%E5%84%AA%E9%BB%9E%E6%98%AF%E4%BB%80%E9%BA%BC-c926145078a4)
[初探 Server-Side-Rendering 與 Next.js](https://medium.com/starbugs/%E5%88%9D%E6%8E%A2-server-side-rendering-%E8%88%87-next-js-%E6%8E%A8%E5%9D%91%E8%A8%88%E7%95%AB-d7a9fb48a964)