前端頁面和後端代碼部署在一個項目裡面，算前後端分離麼？
之前我對前後端分離的理解是，先拿到html頁面，再通過ajax獲得數據顯示出來就是前後端分離，但是又聽別人說，得後端代碼和前端的頁面分成倆項目纔算前後端分離，到底哪種說法對呢？
一直有很多人問，這樣這樣算前後端分離嗎？那樣那樣算前後端分離嗎？好像沒有一個統一的標準。
其實，就是沒有標準，只有程度不同。
就好像你和女朋友分手。
老死不相往來，互刪一切聯繫方式，算分手嗎？
老死不相往來，不刪聯繫方式，偶爾點個贊，算分手嗎？雖不見面，但是偶爾有事還會打個電話，算分手嗎？有時候還會見個面，聊聊彼此過得怎麼樣，算分手嗎？前後端分離也是一樣的，有不同層次。主要看：技術(語言、框架、工具)分離，人員分離，開發分離、部署分離。
技術分離：
前後端使用不同的技術，這個其實也是前後端分離的驅動因素。前端用HTML、ESTS、CSS等語言，用NG/React/Vue等框架，npm、webpack等工具。伺服器端用用Java、Kotlin、SQL等語言，用Spring框架，用Maven等工具。
這一點很容易理解。只要不錯誤的把JSP當成前端技術就行。人員分離：
因為上面的技術分離，造成一個人同時會前後端就要求太高了。畢竟術業有專攻，技術需要細分領域。所以人員分成前端團隊和後端團隊。
有的公司沒有明確區分。主要是前端發展起來的較晚，後端團隊佔主導地位，前端團隊是從屬地位。或者後端找幾個熟悉JS的人寫前端。
開發分離：
兩個團隊分別有自己的開發過程。面向需求，商討API，然後同時並行開發。最後集成、測試。
部署分離：
前後端在邏輯上或物理上分開部署。
可能同一臺伺服器，前端用Apache HTTP Server、Nginx、Node部署，伺服器端用自己的應用伺服器部署(例如Java用Tomcat)。
或者，前端有自己的專屬伺服器或伺服器集羣，伺服器端有自己的專屬伺服器或集羣。
有的前端開發完，編譯產生的靜態文件，覺得沒必要單獨部署，就會放到後端應用伺服器裏，作為應用伺服器的靜態資源。畢竟這些伺服器天生就可以提供HTTP Web服務。
當前問題只涉及到這個層面，也就是部署沒有分離，是前後端分離的一個層次。
回到戀愛分手這個例子上來。
前後端使用不同的技術，但只有一個團隊，不分工，是前後端分離嗎？
兩個團隊，但是後端主導開發，前端總是聽後端的指揮，是前後端分離嗎？前端和後端獨立開發，只有API上的對接，但是最後前端的成果放在後端的額應用伺服器裏，是前後端分離嗎？前後端分離開發，分離部署，是前後端分離嗎？只是程度不同而已。
@Nimo
我認為JSP是後端技術，前端功能，屬於前端代碼。或者說他是客戶端所需的渲染技術。只是現在渲染模版的工作從伺服器端就到了客戶端，比如大家都用vue渲染了。 有點繞口就像是ssr是伺服器端技術，但是是前端工作。我對JSP的核心觀點是：如果必須要寫jsp，那麼jsp是前端的工作內容，前端寫jsp就是分離，還是後端寫jsp就是不分離。
看了你上面的回復，也看了你在這個問題下自己的回答。
JSP是Java Server Page，是伺服器端技術。因為：
- 用伺服器端Java寫的，有自己的一套標籤庫JSTL，這些標籤庫也都是Java提供的。
- 運行時在伺服器端，必須有容器提供運行時環境。
- JSP作為View，和Controller交互數據，純粹在JVM裏發生，完全是一體的。
- JSP僅僅把在伺服器端渲染好的HTML響應/返回(Response/return)給瀏覽器，返回之前的一切都發生在伺服器端的容器裏。
- 如果認為JSP是前端技術，那麼純Servlet也算前端技術了？因為JSP能做的Servlet都能做。JSP只是為了方便輸出HTML才基於Servlet發布的新規範。
有一種情況，就是JSP寫的非常簡單。簡單到已經沒有JSP本身該實現的功能，僅僅是擴展名還是jsp而已。頁面裡面用了前端框架，用了大量JS和CSS。JSP渲染後的HTML響應給瀏覽器，瀏覽器再運行HTML中的前端框架和伺服器端進行AJAX交互。
這種情況很容易發生在只有老伺服器團隊，剛開始嘗試前端框架，或剛開始嘗試前後端分離的時候。
在你自己的回答中，你開頭提到：要思考為什麼要分離。
前後端分離，是架構上最大和最徹底的松耦合。松耦合的目的是為了效率和靈活性。效率又包含兩層含義：開發效率，運行效率。
人員分離、開發過程分離，就是為了提高開發效率。前後端專註於自己擅長的技術，並且能松耦合，並行開發。
部署分離，是因為有了松耦合，就可以提高架構靈活性，以及運行效率。
例如，互聯網產品，需要CDN。可以把前端框架生成的JS、HTML、CSS、圖片都發布到CDN上去。
個人記錄分離的目的在於解耦。所以前後端分離沒有明確的界線。而在於程度。就和三分甜，五分甜，七分甜一樣。
前後端分離我理解分離的場景如下：
1技術分離(不出現jsp這種和傳統後端耦合的場景)
2代碼分離(代碼倉庫獨立維護)
3部署分離(前後端可獨立部署)
4業務分離(前後端業務完全拆開，前端有自己的BFF服務)
大部分前後端分離都能做到1,2,3。每做到一點分離的程度就深一點。
你說的是對的。
前後端分離的幾個階段： 框架分離、交互分離、人員分離、部署分離。
只有實現了部署分離的前後端分離，纔算是真正的前後端分離。並不是很多人以為的，換個vue的框架，前後端用ajax通信就叫前後端分離。
如果你們的項目同時有APP和pc web端，很容易理解這個部署的問題。原生APP就是真正的從開發到部署完全分離的結構。比如ios上的app，發布在appstore，運行在ios系統上，這個發布部署都是ios開發人員的職責，和服務端是完全的兩個項目。與此對應的，前端的項目打包後也是由前端人員負責上線和維護的。我們通常使用nginx部署，用反向代理解決跨域問題。
我就遇見過很多搞服務端的搞不清這層關係。前端打個包，最後又把代碼扔進tomcat下和java項目部署在一起。當你有多個版本發布時，這種做法會在升級上造成很大的麻煩，同時也容易造成許可權管理的混亂。
我盡量用能夠簡單理解的語言來解釋你的問題
頁面和後臺部署在一個項目還是多個項目，只是物理上的分離與否。
你說的html寫頁面，用ajax來call api拿數據再展現出來，這是邏輯上的分離。
這兩種分離可以排列組合成4種結果
1。物理不分離，邏輯不分離。代表，遠古時代的asp或者php，業務邏輯全部夾在html裡面，現在一般不這麼做了，即便寫個簡單的東西也不會這麼做。
2。物理分離，邏輯不分離。代表，古代的asp. Net或者vb. Net，後臺邏輯單獨起項目，通過wcf或者rpc調用，雖然頁面已經有code behind，但是不能避免頁面還是html夾雜一堆代碼。(當然你可以說不用伺服器控制項，通過. Aspx頁面或者html的ajax去call寫在. ashx的介面，或者其他restful api，但是這並不是asp. Net的典型應用，而是人為的三層結構，不在討論範圍)，現在一般也不會這麼做了。
3. 物理不分離，邏輯分離。這種很少，一般如果做一個很小的工具或者網站，不需要考慮太多可擴展性。可以這樣做。比如做個企業員工查工資/績效/年假的微信服務號應用頁面。這就是你說的前端html通過ajax call後臺介面，但是都部署在一個工程裏。
4。物理分離，邏輯分離。這是現在的普遍做法，甚至會分的很細，分很多個工程。
比如大型網站在物理上，前臺有web server，有負載均衡，有緩存server，有mq serverq ，中間有各種業務server，有各種中間件，底層有數據接入server，有db server(不止一個)等等。
從邏輯上來說就更加複雜了，可能一個網站或者系統有web，有app，有wechat，還有desk application，各種client都用不同技術棧單獨部署，可能有的是call restful api，有的是call web service，有的是直接集成sdk，後端部署可能更加複雜，有些可能上了microeservice框架，有些legacy模塊可能還是保留rpc調用，有些是web service，還有些。。。還有些可能現在正在維護的程序員也不知道是怎麼回事，不要隨便動就完了。
所以前後分離只是一種思想，並沒有一定的正確標準，選擇適合你的項目的架構即可
不在乎形式，在乎理念
推薦閱讀：
