沒有前後端分離的世界
以前的專案架構基本上就是全端自己搞全部的東西：後端自己把資料送到頁面上，然後接收頁面傳回來的資料，再決定要做什麼處理。
這樣做的好處是人力少，寫的人自己知道自己在寫什麼，環境單純、自己維護。
壞處是當其他人要接手時，根本交接不出去，因為其他人不知道你寫的東西是什麼邏輯。
分離與不分離的比較
前後端不分的優點
- 單一頁面維護成本低
- 程式一致性高
- SEO 不是問題
前後端不分的缺點
- 整體架構與團隊維護成本高
- 程式耦合性高
- 團隊成員需要都是全端
前後端分離的優點
- 單一職權更專精
- 有分工、有文件，協作更容易
- 架構一致性高
- 可以使用任何前端框架
前後端分離的缺點
- 溝通成本高
- SEO 是個大問題（需要 SSR）
- Debug 需要懂前後端的人才能精準定位問題
反思
沒有說一定要上分離架構比較好，但反過來講，當分離的利大於弊時，是什麼原因讓你不想採用？
轉型所需條件
假定想要從前後端不分轉成前後端分離架構，需要具備：
- 懂前後端分離的前後端工程師
- 懂前後端介接的全端工程師
- 專案架構足夠成熟，已分離大部分耦合性問題
- 持續改善專案的責任感與好奇心
前後端分離想解決什麼？
大概 2015 年左右，頁面元素還沒那麼複雜，切版還可以用 table，前端基本上是可有可無的存在。
但後來幾年，前端框架大爆發，要求更多、更美、更快、互動性更高。這時候後端或全端就搞不清楚前端現在的東西到底怎麼用了。
你也不可能叫後端來幫你看怎麼調前端打包設定檔，對吧？更不要說前端效能優化這些更深的問題。
真的前後端分離了嗎？
答案基本上是：不算有。
除非直接上 Next.js / Nuxt.js 這種前端 SSR 架構，再跟後端 API 取得頁面內容，否則都不算真正的前後端分離。
但實際上不太會有公司往這個方向走，因為願意花時間了解 Node.js 的前端工程師不多。