你是小阿巴，剛入職的全棧程序員。
所謂全棧，就是
當用户打開一個網站，能直觀看到、可交互操作的界面，就是前端。
而當用户點擊操作按鈕後，觸發的操作驗證、數據查詢、業務邏輯處理等種種 “看不到” 的操作，都由後端來完成。
本文對應視頻版：
你使用的開發技術是比你年齡都大的 JSP，它的特點是把前端 HTML 網頁代碼和後端 Java 代碼混在一起寫。
剛開始項目代碼不多的時候，你寫的很舒服。
但隨着項目越做越大，更多同事加入了這個項目的開發，你也漸漸發現了幾個問題。
-
代碼混亂難維護：前端後端代碼糾纏在一起，不利於閲讀，也不利於排查 Bug。
-
團隊協作困難：你在改前端樣式，同事在改後端邏輯，經常改着改着就衝突了。
-
人員要求更高：開發人員必須同時學習前端和後端技術，今天寫 CSS 調樣式，明天寫 SQL 查數據庫，根本忙不過來。
-
部署效率低下：由於前端後端寫在一起，哪怕改個按鈕顏色都要重新編譯部署整個項目。
受這些問題的影響，項目開發效率越來越低，Bug 卻越來越多，你壓力山大、發如雨下。
老闆看出了你毛兒的不易，給公司請來了一位新的技術導師，號稱 “全棧冤種” 的魚皮。
魚皮看了看你的項目，搖了搖頭：連前後端分離都不做麼？
你疑惑地問：前後端分離？沒聽説過。
這時，你的同事阿土申插嘴道：我知道啊！我們現在把前端靜態文件放在 static 文件夾，JSP 代碼放在 jsp 文件夾，這不就是前後端分離嗎？
魚皮皺眉：那只是文件夾分離，不是真正的前後端分離。
阿土申不服：魚皮老狗，那你説説用什麼技術才算是前後端分離？
魚皮笑道：前後端分離可不是某種特定的技術，而是一種
看看你們現在的項目，用户訪問網站時，是由後端服務器接收請求，然後在後端查詢數據並拼接到 HTML 網頁模板中，生成完整的網頁，最後再返回給用户。
顯然，後端承受了太多！
而如果改造為前後端分離：
-
前端專注於用户界面的呈現和交互邏輯
-
後端專注於數據處理和業務邏輯，不涉及界面代碼和網頁生成
-
用户在前端進行操作時，前端通過
你不明覺厲：可是這樣做有什麼好處呢？
魚皮指着你之前列出的問題説：前後端分離就是專門解決這些痛點的！
1）首先是
2）代碼分離後，就可以
3）還可以
4）做到前面 3 個分離後，我們便能實現前後端分離的本質 ——
聽着魚皮滔滔不絕，你雙眼放光：前後端分離這麼厲害，是不是還能提升網站性能呢？
魚皮搖搖頭：不一定，而且有時前後端分離可能更慢！因為用户訪問網站時，瀏覽器需要先加載前端頁面，然後執行 JavaScript 腳本請求後端數據，這比傳統的後端直接返回完整頁面多了一次網絡請求。
但是也別灰心，前後端分離後，前端和後端都可以分別進行優化，更靈活。
你點了點頭：原來如此，看來前後端分離的主要目的是
於是你帶領團隊開始重構項目，前端用 React 框架重寫了整個界面，打包成靜態文件部署到 CDN 加速網絡上；後端則專門提供 API 接口，返回 JSON 數據，部署在獨立的服務器上，互不影響。
幾個月後，你感受到了前後端分離的優勢：
-
團隊成員各司其職
-
前端技術靈活選擇
-
後端服務多端複用
雖然前端和後端對接的過程中偶爾會鬥嘴打架，但你也通過自己總結的一套前後端分離的實戰經驗完美解決。
你興奮地對魚皮説：前後端分離也太爽了吧！
魚皮笑着問：那我問你，前後端分離一定比不分離更好麼？
你不假思索：那當然了！你看看這盛世豈不如你所願？
魚皮搖搖頭：小阿巴你要記住，沒有最好的架構，只有相對更合適的架構！是否採用前後端分離，要根據團隊項目規模、項目實際需求、團隊技術能力等綜合決定。
你：我明白了，拋開實際場景談架構都是耍流氓~
魚皮：最後問個問題，用了 React 框架一定就是前後端分離麼？
朋友，説説你的看法吧。
