曾嘟嘟
前後端分離的演變
記得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開發桌面化已經是無法阻擋的潮流，而前端開發的需求應該會向更加註重界面表現，速度流暢，用戶體驗的方向發展，而且要求只會越來越高。
而在後端穩定、性能、安全、存儲和業務等核心問題依然是主流，所以前後端的需求必將日益分化，注重表現和注重內在的前後端開發人員必將需要適合自己的舞臺。
更多精彩內容請關注“IT實戰聯盟”哦~~~
IT實戰聯盟
我喜歡這樣的問題。
如果是問“什麼是正確的前後端分離”，我還真不敢回答，生怕自己的理解有什麼偏差；但是問怎麼“理解前後端分離”，那我可以結合自身的工作，談談我對前後端分離的理解，也歡迎大家提出不同的理解。
我07年參加工作就是做企業級項目的開發，那時候的一些項目都只有一個包，沒有什麼代碼規範，業務邏輯散落在各處，甚至是JSP中直接訪問數據庫並做業務處理。
後來逐漸有了一些規範，頁面就是頁面，代碼就是代碼，很多項目開始使用Ajax框架。
發展的更進一步，後端代碼有了分層，cotroller/service/dao，可能每個項目分層策略不同（三層和兩層居多），每層的叫法不同（cotroller還是action），數據從頁面到最後訪問數據庫，需要走到多個分層中。
不過到了此階段，在企業級項目的開發過程中，Java程序員依然要兼顧前後端的開發，所以前端頁面的樣子嘛，達不到美觀的程度，也就是能用。
繼續發展，很多項目開始變成了前後端分離。對於前後端分離的定義我是這樣理解的：
頁面是頁面，代碼是代碼，但是他們在一個包中，這個肯定不能算前後端分離；
前端頁面一個程序包，後臺代碼一個程序包，兩個包都需要部署到Tomcat上，前端調用後臺的接口；我認為這個也不是嚴格的前後端分離，但是我覺的這樣做也沒有問題；
如果前端只有HTML文件，放到HTTP服務器上，瀏覽器只訪問獲取這些HTML就好了，數據是從後臺程序提供的接口獲得；這樣才算是前後端就分離了。
前後端分離有很多的好處：前端開發和後端開發可以各司其職，約定好接口之後就可以並行開發；後端接口可以複用，如果項目同時有電腦網頁端、移動網頁端、APP端等多個入口的時候，後端可以只有一個；
帶來好處的同時，也會有一些缺點，例如：增加了架構的複雜性，如果技術能力不足的團隊，可以考慮半分離（例如我們部門都是企業級應用，都沒有前端開發人員）；如果是面向互聯網的應用，需要搜索引擎抓取，就需要服務器端渲染；另外前後端交互的接口，也需要花時間和精力設計。
最後，是否需要使用前後端分離，還需要根據項目的實際情況決定。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
我剛開始做開發的時候目標就是做一個全棧工程師，啥是全棧工程師呢？就是前端，後端，數據庫，運維等樣樣精通，
不管是一開始的HTML代碼直接寫在JAVA代碼裡，還是後來的MVC框架，把業務層和顯示層分開，頁面的代碼和後端業務功能全部耦合在一個項目裡邊，開發人員不僅要處理業務方面的邏輯，還需要控制頁面的展示，甚至於頁面顏色等等非業務方面的交互東西！
最主要的是如果只是頁面需要改變個簡單的樣式，還得把整個應用全部部署一遍，這顯然是極不合理的！
所以前後端的分離極有必要，讓前端來控制與用戶的交互，而後端來實現業務羅，雖然對外作為一個整體，但是前端和後端分別部署，讓前端開發人員和後端開發人員能做自己更加擅長的東西！
前後端的分離通常使用後端服務系統提供接口與前端進行數據交互，前端負責顯示和接受用戶數據，現在用的最多的前後端分離方案是後端微服務+node.js（互聯網大廠都這麼用）！
node.js將js代碼不像是在瀏覽器一樣解釋執行，而是放在了服務端進行環境部署執行，同時node.js使用事件驅動，非阻塞IO的方式能同時支持大量的訪問！
前後端分離之後，就存在跨域（域名不同，協議不同等等）的問題，解決的方式比較多，有nginx配置轉發，CORS配置響應頭等等！
總之，前後端分離就是為了解放前後端的開發人員，讓開發人員能更加專一的進行擅長的工作，前端負責交互，後端負責業務處理，最終形成一個整體的應用系統！
以後全棧工程師這個詞只怕是會越來越遠咯！
哎喲JAVA不錯哦
Java程序員前來分享這個問題。
前後端分離最直觀的理解就是前端程序員幹前端的活，後端程序員幹後端的活。
詳細點說就是由於架構和技術選型，前端和後端高度解耦合，數據傳輸保持一致，代碼互不相干，後端複雜增刪改查的業務操作，最後會有產出一堆數據，一般是json格式，如果通過具備一定規範和約定的接口，流向前端程序。
這個地方有點像插座和插頭的關係，數據像電流，前端提供一個插座板，後端提供一個插頭，數據就開始連接了起來。
至於前後分離的原理這裡不做過多闡述，說說以前前後不分離的時候，後端開發人員可能還要改jsp代碼，硬生生被逼成了一個“全棧”。如今前後分離，後端開發者只需要關注後端代碼怎麼寫，最後統一接口傳輸就可以了。
不過目前有個尷尬的地方，前後端即使分開寫，還是要進行聯調的工作，這就讓系統解耦合度工作人員沒有解耦合。
關注“極客宇文氏”，一名有料的軟件工程師。極客宇文氏
程序編寫的前後端分離有很多好處，既能帶來開發效率的提升，也能帶來執行效率的提升，另外對程序的部署、安全性都會有一定的幫助，所以前後端分離一直是Web開發領域一個很重要的內容。
隨著Web開發技術的不斷髮展，前後端分離從設計到技術都有了較大的變化。早期Web開發基本上採用的是一種耦合式開發，也就是說前端技術和業務邏輯是耦合在一起的，典型的代表就是JSP+JavaBean的開發方式，如圖：
後來提出了MVC的解決方案，JSP專注於顯示，業務邏輯採用Servlet+JavaBean來完成，這種開發方式流行了很長一段時間，經歷了從EJB到Struts再到Spring，一直到Ajax技術的出現，如圖：
再後來提出了HTML+JavaScript的前端解決方案，後端採用微服務的方式來實現，這樣做的好處是前後端徹底分離了，前端頁面也不再與後端服務部署在同一個服務器中了，而是採用了分開部署的方式。這種部署方式增強了Web應用的健壯性和穩定性，也極大的提升了訪問效率，比如目前前端頁面大部分都部署在Nginx服務器上。
對於程序員來說，理解前後端分離的開發方式要能通過代碼實現出來，不僅要對開發技術有所瞭解，更應該知道每個技術的應用場景和性能特點。前後端的分離也能帶來開發效率的提升，前端團隊可以更專注於呈現的效果，而後端開發團隊可以更關注於處理的效率。
我做Web開發時間比較久，我會陸續在頭條寫一些關於軟件開發方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。
如果有軟件開發方面的問題，也可以諮詢我。
謝謝！
IT人劉俊明
以java為例。簡單的理解為。javaweb不再提供試圖。只提供restful格式的api接口。前端框架負責交互和渲染視圖。以api為數據交換中心
killman
程序員不需要了解，設計師不需要了解，架構師不需要了解。因為該知道的都知道了，不知道的也不需要知道。
老闆需要了解、CTO需要了解。前後端分離應該是從上而下的戰略決定，而不是從技術到技術的業務決定。
前後端分離絕對不僅僅是一個技術問題，更是一個綜合性規劃和管理問題。
1、公司規劃和產品規劃層面
產品的用戶體驗對公司很重要，這種情況下前後端分離才很重要，因為這意味著會有更專業的前端開發人員開發前端。所以一般來說ToC的公司前後端應該分離，而ToB要考慮這個問題。
2、人員和組織結構層面
最好有更專業的美工，這很重要，否則這會是用戶體驗的短板，花錢請個美術專業的美工，比請個很牛逼的前端划得來的多。前後端要分開管理，否則領導的技術經驗帶來的思維定勢會很大的影響很多技術決策。人員成本也是需要考慮的，現在前端的工資虛高。
3、技術層面
這裡的重點是前後端結合部分的技術考量。到底是前端為主型還是後端為主型。這就不展開了，一言難盡。
正宗烏龜魚
1、該網站前端變化遠比後端變化頻繁，則意義大。
2、該網站尚處於原始開發模式，數據邏輯與表現邏輯混雜不清，則意義大。
3、該網站前端團隊和後端團隊分屬兩個領導班子，技能點差異很大，則意義大。
4、該網站前端效果絢麗/跨設備兼容要求高，則意義大。
