一 傳統的開發模式
前後端分離前我們的開發協作模式一般是這樣的：
前端寫好靜态的HTML頁面傳遞給後端開發。靜态頁面可以本地開發，也無需考慮業務邏輯隻需要實作View即可。
後端使用模闆引擎去套模闆，同時内嵌一些後端提供的模闆變量和一些邏輯操作。
然後前後端內建對接，遇到問題，前台返工，背景返工。
然後在內建，直至內建成功。
這種模式的問題
在前端調試的時候要安裝完整的一套後端開發工具，要把後端程式完全啟動起來。遇到問題需要後端開發來幫忙調試。我們發現前後端嚴重耦合，還要要求後端人員會一些HTML，JS等前端語言。前端頁面裡還嵌入了很多後端的代碼。一旦後端換了一種語言開發，簡直就要重做。
像這種增加了大量的溝通成本，調試成本等，而且前後端的開發進度互相影響，進而大大降低了開發效率。
二 前後端分離的開發模式
前後端分離并不隻是開發模式，而是web應用的一種架構模式。在開發階段，前後端工程師約定好資料互動接口，實作并行開發和測試；在運作階段前後端分離模式需要對web應用進行分離部署，前後端之前使用HTTP或者其他協定進行互動請求。
1. 用戶端和服務端采用RESTFul API的互動方式進行互動
2. 前後端代碼庫分離
在傳統架構模式中，前後端代碼存放于同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜着後端代碼。前後端工程師進行開發時，都必須把整個項目導入到開發工具中。
前後端代碼庫分離，前端代碼中有可以進行Mock測試(通過構造虛拟測試對 象以簡化測試環境的方法)的僞後端，能支援前端的獨立開發和測試。而後端代碼中除了功能實作外，還有着詳細的測試用例，以保證API的可用性，降低內建風險。
3. 并行開發
在開發期間前後端共同商定好資料接口的互動形式和資料格式。然後實作前後端的并行開發，其中前端工程師在開發完成之後可以獨自進行mock測試，而後端也可以使用Postman等接口測試軟體進行接口自測，然後前後端一起進行功能聯調并校驗格式，最終進行自動化測試。
分離後，開發模式是這樣的