⑴ 談談前後端分離、模板引擎
答：有兩種方式。
前後端分離：也就是後端服務化，客戶端先拿到的是靜態的html，然後再通過Ajax請求向spring boot後端介面獲取JSON數據，然後再在前端渲染html。
伺服器端渲染:客戶端發起請求，後端servlet接收請求，交給對應請求路徑的controller執行對應方法，方法返回ModelAndView給模板引擎，引擎再根據View找到模板（靜態html）並將Model（一般是map集合）渲染到模板中，再把渲染好的模板寫入響應，這是一個完整的MVC流程。此時客戶端拿到的是已經渲染好的視圖（也就是注入了模板數據的html）。
⑵ Web 前後端為什麼需要分離
我理解的前端就是負責所有和用戶交互有關的模塊都可以視為前端，他就像餐館裡面的前台服務生直接和客戶打交道的人。
後端就是負責處理用戶的請求，進行數據的處理，用戶幾乎所有操作都可以抽象為對數據的增刪改查，就像餐館裡面的廚師接收服務生告訴他要炒哪些菜，廚師把菜處理好再給服務生（後端處理數據返回給前端表現層）服務生最後輸出給客戶。
但是目前由於很多情況下業務比較簡單，比如說一個內容發布系統 CMS ，用戶交互，請求查看文章和管理員新增文章都是很簡單的業務邏輯，所以前後端都用 php 這門主要用於表現層的語言來實現，而本身在用 MVC 模式把用戶交互部分（ V 和 C ）以及數據處理（主要是 M ），否則的話就得用 java 等非腳本語言來實現保證效率，甚至高並發環境下還要用到消息隊列，緩存等等。
⑶ 前後端分離，用偽靜態還有意義嗎
比如點擊獲取更多這種ajax 前後端分離完善的話 偽靜態就沒意義，但是有些框架前後端分離不完善的比如yii 這些的話還是使用偽靜態的好，既然都考慮偽靜態了，為什麼不讓後端做緩存呢？
⑷ 如何使用webpack，proxy實現前後端分離，並且方便後期前後端聯調
分離的痛點是分離後，介面提供不及時，文檔不完善，模擬數據不方便等。說一下我們的解決辦法：
1）webpack設置proxy，這個通過webpack文檔或GOOGLE一下可以解決。
2）第二步就是需要在後端提供介面及數據和介面文檔，而因為前後端很可能是並行開發的，所以在真實介面出來之前需要前端模擬介面及數據，及數據文檔然後在真實介面出來後，切換到真實介面調試，我們之前也遇到過此問題，所以抽時間自己做了個mocksever 系統，功能包括:
支持可視化編輯JSON介面數據及介面文檔
支持GET、POST、PUT、DELETE請求類型
支持指定返回狀態碼，默認200
支持延時返回數據
支持mockjs
支持單個介面代理到真實伺服器(開發過程中某個介面使用模擬數據,當此介面已開發完成後,可將指定介面,通過此服務指向到真實介面上)
⑸ 基於Docker-Compose 部署前後端分離單體項目(一)
1.單體項目是否需要採用docker進行部署?
2.如果採用docker部署是否有必要採用docker-compose進行服務編排？
答案是也許有必要，也許沒必要，docker的優勢很多，但是對於垂直架構的項目優勢未必那麼明顯，總之一句你需要根據自己的項目情況去考慮。筆者之所以會寫這篇文章，大概率是基於省事的目的去部署一些小的項目。同時也是提供一種前後端分離的項目的部署方案(但絕對不是最有方案),以及在這種模式下的docker如何去工作才能達到我們的目的。
然而最終的目的是為了偷懶，省事。讓前後端分離項目的部署方式變的簡單。就也許在這種模式下，你只需要5分鍾就可以實現部署，或許吧，不妨把這個當作一個目標。
本文目標:
上圖將部署流程分為三部分，本地開發環境，阿里雲容器鏡像服務，以及linux伺服器。下面分成三個部分對上圖進行說明，工欲善其事，必先利其器。先進行說明，後面才能對每部分做的工作比較清晰。
本地開發環境分成三個項目
先解釋一下圖中的相關名詞
容器鏡像服務，分門別類的存儲我們的鏡像 。這個是鏡像服務的唯一用途，就相當於maven的倉庫是一樣的。
我們也可以搭建自己的私服倉庫，例如開源的harbor等，都非常好用，在企業中用私服會比較多。
首先我們需要在linux伺服器上搭建Docker環境，也就是我們在linux上有一個docker。再將我們的鏡像運行在docker上。
從上圖我們發現在docker上運行這很多容器，mysql，redis，nginx，pitaya-java,pitaya-admin,pitaya-h5.
然而我們的容器是需要通信的，例如:大家都知道pitaya-java是一個springboot的項目，他需要訪問mysql進行數據存儲服務，需要訪問redis緩存我們的令牌信息等。
也就是說，我們運行的這些容器之間是要相互能通信的。所以我們在docker上創建了一個內部網路叫做pitaya-network，他在172.2.0.0這個網段，我們需要我們的容器都加入pitaya-network這個網路，並且分配固定的IP地址,指定固定埠。
為什麼需要分配固定IP地址，指定固定埠? 因為我們的容器也可能會和伺服器一樣，會掛掉，如果隨機分配的話，創建新的容器，IP地址可能會變，我們容器間不能通信，例如java服務訪問不了mysql，這樣我們的線上就無法提供客戶正常服務了。
本文我們做一個大概的概述，針對上面的結構以下問題是我們急需解決的？
其實針對java項目和vue項目製作鏡像方式不同，但是原理一樣，原理無非就是基於docker build這個命令製作鏡像，但是java的鏡像製作和推送可能更加簡單，只需要一條命令即可，因為maven提供了製作鏡像的插件。這些內容在下一篇文章都會涉及到！
想要表達清楚一鍵事情是非常不容易的事情，特別是通過文字，既不想廢話連篇，又想表達清楚真的很難，因為細節比較多！然而我覺得弄清楚大方向是非常必要的，然後再進行分解，希望能說的明白，我會加油的，如果寫的不好也希望大家原諒！
⑹ 如何進行前後端分離
在不使用vue ,react ,anglar這類的框架的情況下，前後端分離應該如何做？
需求是這樣：
前端寫html頁面（非單頁面應用），
index.html 首頁
about.html 關於我們
newslist.html 新聞列表
newsdetail.html 新聞詳情
proctlist.html 產品列表
proctdetail.html 產品詳情
後台只提供json數據
那麼
1、前端數據如何渲染？
2、頁面跳轉是否必須使用路由？（不想使用路由）
3、頁面間的數據傳遞如何做，比如：列表頁到詳情頁的參數傳遞如何做？
⑺ 使用 MockJs — 實現真正的前後端分離
前言： 剛剛看了下的後台，發現我技術文章中，閱讀留言最多的是關於移動端的文章，甚至還有人付費贊賞或咨詢。關於 PC 端的技術文章就顯得比較冷清了，唉，廢了好大勁寫的，沒人看。 和我想的一樣，移動端才是王道，下次找工作我也搞移動端😂 。
背景： 去年我寫了一篇 學習使用 json-server 和 mockjs 的文章，當時沒有仔細研究，文章只提到了 MockJs 其中一個 Random 的用法，關於 MockJs 攔截器和另一個很常用的 Mock.mock 函數都沒有提及。這次來搞一下。
唉！以前我也是經常會聽到 前後端分離 這個名詞，只模糊的知道它最重要的一個作用就是，大大的提升了 前端的地位。 但是平時在開發的時候，我也會想奶奶的，沒有介面這前端不就寫了一個破頁面，後期還的和後端對介面，對介面的時候花費的時間，肯定是不比前端開發的時候短，工期上最起碼一半一半吧， 這也就前後端分離 ，我這個小腦袋就不是太明白了。
不過我現在是終於搞明白這個問題了， 對於前端來講，真正的前後端分離，標志是不依賴後端的前端工作開發完成，項目基本宣告結束。 後端開發完介面，只需要提換一個 URL 就行了，這也意味著前端需要去寫一些介面。
除了帶來開發任務稍微重點外，我至少看到了兩個最大的優點：
我體會最深就是這兩點。
插曲 ：對了，今天中午我撿到一個手機，我必須要用一張動圖來描述下：
這個經典的 GIF ，來自鄭伊健的恐怖電影「第一誡」，清涼一冬，絕對值得一看，雖然劇情有很大的 bug ，但是港片就這點好，它有很抓人的地方，讓你覺得特別好看。
正文由此開始：
待續~~~
上面三種方案都可以，但你要知道介面很多，需要支持批量引入，所以 使用 Axios 響應攔截器 就不太可取，只能在這簡單的造些假數據。
著名開源項目 vue-element-admin 開發環境下模擬假介面使用的是 在 webpack-dev-server 的 before 處攔截。生產環境下是在項目入口文件（ index,js ）使用 Mock.mock 模擬的。
攔截請求的步驟如下，根據 devserverbefore 配置的栗子🌰：
可知道 before 接收一個函數，函數的第一個參數一般叫 app ，因為它的作用和 express 的 app 是等效的。也就是說這個 app 自帶路由， 正好解決介面批量引入的問題。
在項目中，一般都是這么寫，把邏輯提出去：
./mock/mock-server.js 文件的內容為：
./mock/index.js 文件的內容為：
mockXHR 不用看，因為這是給線上環境用的，所以可以簡單的改寫為：
隨便找一個，例如 user 看下介面怎麼寫的：
完美，到此結束。
我想你一定對更改文件的時候，為什麼要 清路由和清緩存感興趣。
如果熟悉 express 框架，看到 app._router.stack 你就知道了。不知道也沒關，我演示給你看，新建一個JS 文件，文件內容為：
執行結束，看在 test.js 文件的內容：
發現沒，重復被添加的路由，不是覆蓋而是擴展。
這個涉及到 CJS 模塊的運行機制， 記住 require 的文件會被加到 require.cache 裡面，當文件改變讀的是緩存，而不是最新更改的文件。
項目結構過大，如果只在 mock 文件夾裡面管理有點麻煩，我就想在頁面所在目錄直接寫介面，怎麼辦？沒錯使用 require.context 來批量引入。但是 NodeJs 是沒有批量引入的 API 的。找遍了 npm 也沒發現一個 package 和 require.context 長得像的。
難道沒辦法了嗎？當然不是，自己動手豐衣足食。 依照 vue-cli 插件的命名規范，我給寫的 package 取名 node-plugin-require-context ，簡單講下實現原理：
其實還有一個缺點，如果你看過 Antd-Pro 項目，你就會發現它模擬數據，模塊化採用的是 ESMole ，而不是 CJS。保持編碼模塊化風格一致確實也是需要優化的一個地方，不管了，反正我不幹。
官網本來就是中文的，我在使用中發現寫的賊好，我就不用畫蛇添足了。建議每次使用前：
⑻ 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
⑼ 前後端分離微服務架構如何設計
前端
前端開發人員專注業務的頁面呈現，非常注重用戶體驗度，也是與各種角色打交道最多的。
比如：
一般前端工作包括六個部分：
後端
如果前後端職責劃分很清楚的話，後端更多開發工作在於業務介面設計、業務邏輯處理以及數據的持久化存儲，並提供詳細的介面設計文檔給前端開發人員使用。
一般後端工作包括五個部分：
1、與產品經理對接需求
2、業務 API 介面開發：根據根據需求文檔進行業務介面開發
4、介面對接：與前端開發人員介面對接
5、前後端聯調測試：包括頁面展示以及介面數據
6、bug修復
前端開發技術棧
h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等
後端開發技術棧
SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、資料庫、緩存框架（ Redis ， Codis , Memcached 等），大數據框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等
技術選型
最好選擇成熟穩定，易上手、開發效率高的技術，因為實際項目開發時間是有限的，開發人員沒有多少精力放在學習和深度研究技術上。
數據格式
後端開發提供介面設計文檔，詳細寫明每個介面的請求地址、請求參數、響應參數等等；一般採用 REST 風格以 JSON 格式提供數據。
介面設計
一個介面設計的好壞，直接影響到前後端的一些溝通協調問題。
依筆者的經驗來看，如果後端介面不穩定，會導致前端開發人員反復修改頁面數據呈現。常常出現後端開發說這是前端問題，前端開發說是後端問題，來回扯皮，溝通效率低下。
介面容量問題
一個介面的業務容量大小，往往代表前後端工作量的大小。
如果一個介面的業務容量太小，前端需要分階段處理的事情就多，尤其是對多個介面 Ajax 非同步處理；
如果一個介面的業務容量太大，那麼業務耦合性高，萬一需求變更，後端程序改動大，不利於程序的擴展。
一、前後端分離的思想要轉變
不能老是按照傳統WEB（ js/h5/css/ 後端代碼放在一個工程）開發思維去看待前後端分離
二、溝通成本問題
以前傳統 WEB 開發，開發人員從需求到設計到開發基本上是一個人。
而前後端分離後，前端只負責頁面呈現，後端更注重業務邏輯處理以及數據的持久化，雙發都有自己的側重點，工作量上有私心。
三、組織結構問題
康威定律
第一定律： Communication dictates design （組織溝通方式會通過系統設計表達出來）
第二定律： There is never enough time to do something right, but there is always enough time to do it over （時間再多一件事情也不可能做得美，但總有時間做完一件事情）
第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （線型系統和線型組織架構間有潛在的異質同態特性）
第四定律： The structures of large systems tend to disintegrate ring development, qualitatively more so than with small systems （大的系統組織總是比小系統更傾向於分解）
康威定律說明以下幾點
四、部署及監控運維
前後端分離後，拆分的服務會帶來線上部署以及如何監控運維的復雜性。
總體來說，前後分離所帶來的好處還是更明顯的。一個成熟的前後端分離的團隊，文檔化約定，前後端職責分離、介面約定都是做得比較好的
⑽ Web項目開發為何要走前後端分離模式
把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發，開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專注於具體業務邏輯。具體好處有以下幾點：
1.徹底解放前端
前端不再需要向後台提供模板或是後台在前端html中嵌入後台代
2.提高工作效率，分工更加明確
前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
3.局部性能提升
通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4.降低維護成本
通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。
5.實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。
6.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。
7.可以使後台能更好的追求高並發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。
我理解的前後端分離，前端是需要起伺服器的，減少學習成本，可以用node，前端也要有域名的
如果是半分離， 那麼前端提供js文件（css等）這個我也做過，前後端都用node就不說了，如果是兩種語言，
如果一個工程文件下開發，webpack下直接打包進後台語言的靜態目錄下。
如果是兩個工程，那麼前端只提供生成的js（css）文件，git pull後台項目，扔進靜態目錄，這樣又涉及到版本控制的問題，一般我會生成一個配置文件，直接讀取的，內容是xxx.hash.js這種文件名，然後document.wirte動態寫入js/css
前端起伺服器就不需要動態引入了，直接html插件生成文件，更好的控製版本
半分離 還有一個問題，例如首頁同構，如果更改xxx.blade.php文件，這就又動了php文件，甚至包括nginx反向代理啊，ssl這種緩存啊，都比較麻煩，你要是改了點啥，自己的ok了，後台的崩了，那就挺操蛋了，大公司有專門的運維還好，小公司真的是一團糟
後台我們採取全分離，nginx前端管理，至於升級nginx版本，http2，反向代理，https證書，都是前端自己弄，畢竟小公司，每個人水平都不一致，自己負責自己的比較好
但是這個跨域又要稍微處理一下，至今我這邊後台還是*，我也沒法說什麼
阿里雲這么便宜，如果把成本浪費在人力上，會變得很貴
一個人的精力有限，前後端分離有助於我們更專注我們所要注重的技術點，俗話說：「術業有專攻」。
比如我們後端，前後端分離有助於我們把注意力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分布式架構（bbo，bbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。
而前端也可以集中精力在前端的展示上。
總的來說，前後端分離利大於弊。這也是越來越少用jsp的原因。
補充兩點
1.每次請求的數據量變小，也意味著更少的響應時間。
2.也不是每個應用用前後端分離都是最合適的，要根據應用規模，工期綜合判斷。