前後端分離等級表
記得一開始寫網頁的時候（大概是 2009 年），就有在考慮前後端分離了。原因是當時有一位合作夥伴主攻前端，而我以前有玩過 Linux 與架站，所以就往後端研究。
對後端越來越熟之後，漸漸地只想待舒適圈不想學前端，於是就認真研究如何順利地做前後端分離。至今，前後端分離聽過也做過非常多方法，只是有時候會無法清楚其他人提到的前後端分離情境為何，今天來試著做個等級表，將這些方法分類，希望能幫助到大家討論對焦。
前提參考：
- 這是一個從全端開發變成有前後端分離開發的過程，因此等級越低，前端的存在感越低；而等級越高，前端所能控制的事，以及要做的事就越多
- 每個等級都有「注意事項」，是這個等級容易遇到的問題
- 雖然 MVC 有助於前後端分離，但此等級表與 MVC 沒有直接關聯
Level 1
依檔案分類做為前後端分離的依據，如 .php 是後端負責的程式、.js 與 .css 則是前端負責的程式。前後端整合方法是由前端先切好版，產生 HTML / CSS / Javascript 等檔案後，再交由後端轉換成後端程式。
注意事項
這是一開始沒有設計架構的前提下，硬是切出一個前端職位的狀況。最常遇到都會是整合上的問題：
- 因為後端不熟前端，因此造成轉換出來的程式並非前端所預期的
- 因為前端不熟後端，因此造成撰寫與後端互動的 Javascript 程式，並非後端所預期的
當遇到這一類問題，就會兩個人坐在同一台電腦上 pair programming。當然 pair programming 很好也沒什麼錯，問題是，這就違反一開始要前後端分離的構想。
Level 2
前端開發時，AJAX 直接串接後端提供的 API；後端制定串接 API 文件，讓前端能參考文件寫出可用的程式，HTML 依然由後端維護與輸出。這個方法理論上能順利完成前後端整合。
注意事項
計劃永遠趕不上變化，文件變化永遠趕不上程式進化。遇到的問題通常為：
- 文件需要維護，開發才會順利，但通常沒有人想維護文件
- 若後端調整格式或是改壞程式，將會影響前端開發
- 若後端 API 有做 session 驗證的話，則前端開發時會無法呼叫此 API，依然還是得交由後端處理
HTML 轉換的問題依然會存在，但因 HTML 本來就由後端輸出，因此通常比較容易開始的會是 Javascript 呼叫。
API 規格不一致的問題，或是後端改壞程式的問題，後面 Level 3、Level 4、Level 5 都一樣會遇到。
Level 3
前端直接使用後端所提供的 HTML 樣板引擎（template engine）作為頁面輸出 HTML 的主要方法，樣版所需要的參數也由後端提供，後端不參與修改 HTML。而輸出 HTML 後，使用 AJAX 跟後端做互動。
從這個等級開始，前端是「有機會」在本機架設隔離且相較真實的環境開發，前兩個等級則只能依賴後端處理，或使用後端提供的環境做開發。
這是我個人所認為前後端分離最平衡的選擇。
注意事項
- 前端需學習樣版引擎，即便相同的後端語言也會有多種樣版引擎，如 PHP 就有 Smarty、Blade、Twig、Volt 等，非常多選擇，就連 PHP 本身也是樣版引擎。
- 前端不需要完全了解後端語言，但仍需了解後端傳給前端參數的用法，以及部分後端語言的特性，如迴圈與判斷等。
Level 4
因瀏覽器一定要跟後端要 HTML 才會開始做畫面的渲染（render），除了 HTML 由後端輸出以外，其他 DOM 元素產生或路由處理，全部交由前端負責。
從這個等級開始，已經屬於是 SPA（single page application）了，前端調整 DOM 元素的內容或前端的路由，完全不需要依賴後端。但 session 狀態管理依然需要後端處理。
注意事項
- 後端只會固定輸出最開始的 HTML，因此 SEO 會需要思考該如何處理
Level 5
這是最終階段，前端的程式已經有如 App 一般，可以獨立放在任何狀置的瀏覽器執行。
此等級與 Level 4 的差異是：由前端管理最開始輸出的 HTML 內容，做法有很多種：
- 直接讓前端管理 Server 回傳的 HTML 內容
- 使用 AWS S3 + AWS CloudFront 作為 Web 服務
- 使用 GitHub Pages 作為 Web 服務
注意事項
最初的網頁輸出已不在後端，因此身分驗證將會是一大難題，可參考 RFC 8252 - OAuth 2.0 for Native Apps 了解相關的細節。
除了參考其他規範外，另一個也很直接的解法是：讓前端多做後端驗證的事即可，比方說寫 Node 伺服器來做身分驗證與 API proxy。
小結
最後還是提醒一下，雖然旨在討論如何前後端分離，但不管是前端還是後端，了解不同領域的知識，對合作才會有實質上的幫助。