以java為例。簡單的理解為。javaweb不再提供試圖。只提供restful格式的api介面。前端框架負責互動和渲染檢視。以api為資料交換中心

1、該網站前端變化遠比後端變化頻繁，則意義大。

2、該網站尚處於原始開發模式，資料邏輯與表現邏輯混雜不清，則意義大。

3、該網站前端團隊和後端團隊分屬兩個領導班子，技能點差異很大，則意義大。

4、該網站前端效果絢麗/跨裝置相容要求高，則意義大。

程式編寫的前後端分離有很多好處，既能帶來開發效率的提升，也能帶來執行效率的提升，另外對程式的部署、安全性都會有一定的幫助，所以前後端分離一直是Web開發領域一個很重要的內容。

隨著Web開發技術的不斷髮展，前後端分離從設計到技術都有了較大的變化。早期Web開發基本上採用的是一種耦合式開發，也就是說前端技術和業務邏輯是耦合在一起的，典型的代表就是JSP+JavaBean的開發方式，如圖：

後來提出了MVC的解決方案，JSP專注於顯示，業務邏輯採用Servlet+JavaBean來完成，這種開發方式流行了很長一段時間，經歷了從EJB到Struts再到Spring，一直到Ajax技術的出現，如圖：

再後來提出了HTML+JavaScript的前端解決方案，後端採用微服務的方式來實現，這樣做的好處是前後端徹底分離了，前端頁面也不再與後端服務部署在同一個伺服器中了，而是採用了分開部署的方式。這種部署方式增強了Web應用的健壯性和穩定性，也極大的提升了訪問效率，比如目前前端頁面大部分都部署在Nginx伺服器上。

對於程式設計師來說，理解前後端分離的開發方式要能透過程式碼實現出來，不僅要對開發技術有所瞭解，更應該知道每個技術的應用場景和效能特點。前後端的分離也能帶來開發效率的提升，前端團隊可以更專注於呈現的效果，而後端開發團隊可以更關注於處理的效率。

如果有軟體開發方面的問題，也可以諮詢我。

程式設計師不需要了解，設計師不需要了解，架構師不需要了解。因為該知道的都知道了，不知道的也不需要知道。

老闆需要了解、CTO需要了解。前後端分離應該是從上而下的戰略決定，而不是從技術到技術的業務決定。

前後端分離絕對不僅僅是一個技術問題，更是一個綜合性規劃和管理問題。

1、公司規劃和產品規劃層面

產品的使用者體驗對公司很重要，這種情況下前後端分離才很重要，因為這意味著會有更專業的前端開發人員開發前端。所以一般來說ToC的公司前後端應該分離，而ToB要考慮這個問題。

2、人員和組織結構層面

最好有更專業的美工，這很重要，否則這會是使用者體驗的短板，花錢請個美術專業的美工，比請個很牛逼的前端划得來的多。前後端要分開管理，否則領導的技術經驗帶來的思維定勢會很大的影響很多技術決策。人員成本也是需要考慮的，現在前端的工資虛高。

3、技術層面

這裡的重點是前後端結合部分的技術考量。到底是前端為主型還是後端為主型。這就不展開了，一言難盡。

我喜歡這樣的問題。

我07年參加工作就是做企業級專案的開發，那時候的一些專案都只有一個包，沒有什麼程式碼規範，業務邏輯散落在各處，甚至是JSP中直接訪問資料庫並做業務處理。

後來逐漸有了一些規範，頁面就是頁面，程式碼就是程式碼，很多專案開始使用Ajax框架。

發展的更進一步，後端程式碼有了分層，cotroller/service/dao，可能每個專案分層策略不同（三層和兩層居多），每層的叫法不同（cotroller還是action），資料從頁面到最後訪問資料庫，需要走到多個分層中。

不過到了此階段，在企業級專案的開發過程中，Java程式設計師依然要兼顧前後端的開發，所以前端頁面的樣子嘛，達不到美觀的程度，也就是能用。

繼續發展，很多專案開始變成了前後端分離。對於前後端分離的定義我是這樣理解的：

頁面是頁面，程式碼是程式碼，但是他們在一個包中，這個肯定不能算前後端分離；

前端頁面一個程式包，後臺程式碼一個程式包，兩個包都需要部署到Tomcat上，前端呼叫後臺的介面；我認為這個也不是嚴格的前後端分離，但是我覺的這樣做也沒有問題；

如果前端只有HTML檔案，放到HTTP伺服器上，瀏覽器只訪問獲取這些HTML就好了，資料是從後臺程式提供的介面獲得；這樣才算是前後端就分離了。

前後端分離有很多的好處：前端開發和後端開發可以各司其職，約定好介面之後就可以並行開發；後端介面可以複用，如果專案同時有電腦網頁端、移動網頁端、APP端等多個入口的時候，後端可以只有一個；

帶來好處的同時，也會有一些缺點，例如：增加了架構的複雜性，如果技術能力不足的團隊，可以考慮半分離（例如我們部門都是企業級應用，都沒有前端開發人員）；如果是面向網際網路的應用，需要搜尋引擎抓取，就需要伺服器端渲染；另外前後端互動的介面，也需要花時間和精力設計。

最後，是否需要使用前後端分離，還需要根據專案的實際情況決定。

前後端分離的演變

記得12年從事工作的時候公司還沒有專門的前端人員，一般我們都是前後端都會，畢竟那時候H5才剛剛起來微軟的XP還在流行使用（預設系統自帶IE6），IE的市場份額還是蠻大的。做的產品也沒有很炫酷的特效（如果有也會選擇使用flex），那時候Flash 是超級火的......扯得有點遠了。

在開發的時候也是一邊API介面服務，一邊開發頁面，釋出也是一個釋出包搞定。前端一般只是負責切圖工作，就是將UI設計師的設計圖佈局成靜態頁面，前端是不參與互動邏輯和業務開發的，前端也是當時統一的吐槽物件。當時淘寶的Web架構比較流行基本上都是基於MVC框架webx，所以前端寫好靜態html 然後後端開發人員翻譯成vm模板.....

這樣就導致了前後端工作的分配不均，開發效率慢，程式碼維護量也大。為了解決痛點 慢慢開始前後端分離的架構流行開來 很好的解決了前後端分工不均問題，將更多的互動邏輯分配給前端來處理，而後端則可以專注於其本職工作。例如後臺開發可以有跟多的時間進行後臺許可權控制以及複雜的運算工作，前後臺解耦 ，兩者同時開始推進專案進度，增加開發效率。

如何進行前後端分離

最開始的時候是SPA式的前後端分離法，單純的從物理層做區分（認為只要是客戶端的就是前端，伺服器端的就是後端），這種分法不能滿足前後端分離的需求，認為從技術職責上劃分才能滿足目前我們的使用場景，作者在工作中使用過兩種方案：

第一種：

前端：負責View和Controller層。

後端：只負責Model層，業務處理/資料等。

優點：可以做url design，我們可以根據場景決定在服務端同步渲染，還是根據view層資料輸出json資料，我們還可以根據表現層需求很容易的做Bigpipe,Comet,Socket等等，完全是需求決定使用方式。

缺點：需要前端來寫Controller，以Java語言開發為例，需要前端學會Java開發，這樣在處理複雜的業務邏輯的產品裡雙方都有Java 程式碼方面的重疊。

第二種：

前端：負責View層。

後端：負責和Controller、Model層和業務處理/資料等。

優點：前端不需要學習後臺開發語言，只需要呼叫API服務就好，前後端程式碼分別統一管理起來 形成自己的對接規範。這樣前端可以和不同的後臺語言做對接服務。

RESTful Api和Json搭建前後臺互動

備註：現在公司使用的RESTful 架構，後臺提供一組設計原則和約束條件。

RESTful 主要用於客戶端和伺服器互動類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現快取等機制。

RESTful Api和Json 技術的使用讓前後端互動日益便利

前後端分離以後就存在資料互動的問題,如何快速、簡潔、有效和統一的在前後臺進行資訊的互動,成為分離以後必須考慮的問題。

幸運的是, RESTful思想和Json資料標準的出現,使得這種互動日益便利,在前端,我們耳熟能詳的JS技術和框架對RESTful和Json的支援可以說已經水到渠成. 至於後端,不管什麼語言,什麼平臺都有非常成熟的方案.

前後端的不同發展趨勢使得前後端分離需求日益明顯.

漸進式框架Vue.js

Vue 是一套用於構建使用者介面的漸進式框架。與其它大型框架不同的是，Vue 被設計為可以自底向上逐層應用。Vue 的核心庫只關注檢視層，不僅易於上手，還便於與第三方庫或既有專案整合。另一方面，當與現代化的工具鏈以及各種支援類庫結合使用時，Vue 也完全能夠為複雜的單頁應用提供驅動。

總結：眾所周知，Web開發自出現以來一直存在效能，表現和體驗的先天不足，但時至今日，事實已經並非如此，一些看上去甚至比桌面程式更炫的應用和網站橫空出世，客戶也被吊足了胃口。Web開發桌面化已經是無法阻擋的潮流，而前端開發的需求應該會向更加註重介面表現，速度流暢，使用者體驗的方向發展，而且要求只會越來越高。

而在後端穩定、效能、安全、儲存和業務等核心問題依然是主流，所以前後端的需求必將日益分化，注重表現和注重內在的前後端開發人員必將需要適合自己的舞臺。

Java程式設計師前來分享這個問題。

前後端分離最直觀的理解就是前端程式設計師幹前端的活，後端程式設計師幹後端的活。

詳細點說就是由於架構和技術選型，前端和後端高度解耦合，資料傳輸保持一致，程式碼互不相干，後端複雜增刪改查的業務操作，最後會有產出一堆資料，一般是json格式，如果透過具備一定規範和約定的介面，流向前端程式。

這個地方有點像插座和插頭的關係，資料像電流，前端提供一個插座板，後端提供一個插頭，資料就開始連線了起來。

至於前後分離的原理這裡不做過多闡述，說說以前前後不分離的時候，後端開發人員可能還要改jsp程式碼，硬生生被逼成了一個“全棧”。如今前後分離，後端開發者只需要關注後端程式碼怎麼寫，最後統一介面傳輸就可以了。

不過目前有個尷尬的地方，前後端即使分開寫，還是要進行聯調的工作，這就讓系統解耦合度工作人員沒有解耦合。

我剛開始做開發的時候目標就是做一個全棧工程師，啥是全棧工程師呢？就是前端，後端，資料庫，運維等樣樣精通，

不管是一開始的HTML程式碼直接寫在JAVA程式碼裡，還是後來的MVC框架，把業務層和顯示層分開，頁面的程式碼和後端業務功能全部耦合在一個專案裡邊，開發人員不僅要處理業務方面的邏輯，還需要控制頁面的展示，甚至於頁面顏色等等非業務方面的互動東西！

最主要的是如果只是頁面需要改變個簡單的樣式，還得把整個應用全部部署一遍，這顯然是極不合理的！

所以前後端的分離極有必要，讓前端來控制與使用者的互動，而後端來實現業務羅，雖然對外作為一個整體，但是前端和後端分別部署，讓前端開發人員和後端開發人員能做自己更加擅長的東西！

前後端的分離通常使用後端服務系統提供介面與前端進行資料互動，前端負責顯示和接受使用者資料，現在用的最多的前後端分離方案是後端微服務+node.js（網際網路大廠都這麼用）！

node.js將js程式碼不像是在瀏覽器一樣解釋執行，而是放在了服務端進行環境部署執行，同時node.js使用事件驅動，非阻塞IO的方式能同時支援大量的訪問！

總之，前後端分離就是為了解放前後端的開發人員，讓開發人員能更加專一的進行擅長的工作，前端負責互動，後端負責業務處理，最終形成一個整體的應用系統！

以後全棧工程師這個詞只怕是會越來越遠咯！

以下純屬個人見解：前端頁面的生成不依賴後端組織和渲染，而僅依賴後端資料。也就是說，資料驅動了前端頁面的生成。前端變成了純粹靜態的HTML+JS，後端變成了純粹的API。

我理解的前後端分離:

前端只做檢視展示，

後端只做資料介面處理

最終前端拿後臺傳遞過來資料，展示在檢視上。

中間具體過程可以自己研究。