這是一篇面向移動端開發(fā)者的科普性文章，從前端開發(fā)的最初流程開始，結(jié)合示范代碼，討論開發(fā)流程的演變過程，希望能覆蓋一部分前端開發(fā)技術(shù)棧，從而對前端開發(fā)的相關(guān)概念形成初步的認識。
本文會提供一些示范代碼，然而他們無法運行，也不需要完全看懂，更多的是方便讀者對相關(guān)概念和方案有更加具體形象的感受和更清晰的理解。
1 移動端與前端的區(qū)別
在開發(fā) App 的過程中，我們不會刻意思考開發(fā)流程，因為一切看上去都非常自然?？梢员镜卮_定的內(nèi)容就直接寫死，否則異步發(fā)起網(wǎng)絡(luò)請求并動態(tài)的修改，最后把源代碼編譯成可執(zhí)行的二進制文件供客戶安裝。
前端開發(fā)和移動端開發(fā)就有本質(zhì)的不同了。一個網(wǎng)頁的最終展現(xiàn)樣式受到 HTML CSS 的影響，而 JavaScript 腳本負責(zé)用戶交互。一個頁面不會被編譯成可執(zhí)行文件，它僅僅由幾個文本文件組成，由服務(wù)端明文下發(fā)給瀏覽器并繪制到屏幕上。
下文中可能會反復(fù)提到“渲染”的概念，除非特別說明，它不表示解析 HTML 文檔(DOM)并繪制到屏幕上這個過程，因為這一步由瀏覽器內(nèi)核實現(xiàn)，普通情況下不需要做過多了解和干預(yù)。
網(wǎng)頁可以分為靜態(tài)、動態(tài)兩種，前者就是一個 HTML 文件，后者可能只是一份模板，在請求時動態(tài)的計算出數(shù)據(jù)，最后拼接成 HTML 格式的字符串，這個過程就被稱為渲染。
前端與移動端開發(fā)另一個顯著差異是: 雖然可以在本地調(diào)試 HTML，但實際上這些 HTML 的內(nèi)容需要部署在服務(wù)端，這樣才能在用戶發(fā)起 HTTP 請求時返回 HTML 格式的文本。
2 前端開發(fā)的混沌時代
一開始，我們沒有任何工具，只能靠蠻力。我們知道 Servlet 是由 Java 編寫的服務(wù)端程序，可以方便的處理 HTTP 請求和返回，因此可以直接把 HTML 文本當做字符串返回，也就是上文所說的渲染:
（上下滑動看代碼）
public class HelloWorldServlet extends HttpServlet {
@Override
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType('text/html');
PrintWriter out = resp.getWriter();
out.println('<html><head><title>Hello World Sample</title></head>');
out.println('<body><h1>Hello World Title<h1><h2>' new Date().toLocaleString() '</h2></body></html>');
out.flush();
}
}
理論上來說，我們已經(jīng)可以開始所有前端開發(fā)了，但在這混沌初開的年代，想寫出一份可維護的代碼恐怕得用上“洪荒之力”。把 UI 和業(yè)務(wù)邏輯寫在一起是一種非常強的耦合，不利于項目日后的拓展。也無法要求每個人同時會寫 Java 和前端。
3 后端 MVC
上述方案的問題之一在于邏輯混亂不清，移動開發(fā)者在入門階段大多也經(jīng)歷過，解決方案比較簡單:使用 MVC，把業(yè)務(wù)邏輯抽離到 Controller 中，讓 View 層專注于顯示 UI。
4 MVC 方案實現(xiàn)
在前端開發(fā)領(lǐng)域，也有類似的技術(shù)，比如 JSP，它經(jīng)過編譯后變成 Servlet。在寫 JSP 的時候，我們更加關(guān)心頁面樣式，因此代碼看起來就像是 HTML，不過在 <% %> 代碼塊中可以調(diào)用 Java 函數(shù):
（上下滑動看代碼）
<HTML>
<HEAD>
<TITLE>JSP測試頁面---HelloWorld!</TITLE>
</HEAD>
<BODY>
<%
out.println('<h1>Hello World!</h1>');
%>
</BODY>
</HTML>
JSP 相當于 View 層，它從 Model 中獲取數(shù)據(jù)，說的再具體一點，是使用后端的語言(比如 Java)去訪問 Model 層提供的接口。
Controller 作為直接和客戶端接觸的模塊，負責(zé)解析請求，數(shù)據(jù)校驗，路由分發(fā)，結(jié)果返回等等邏輯。路由分發(fā)是指根據(jù)請求路徑的不同，調(diào)用不同的 Model 和 View 提供服務(wù)。
5 MVC的缺點與改進
使用了 MVC 架構(gòu)(比如大名鼎鼎的 Struts)后，似乎職責(zé)變清晰了，前端開發(fā)者負責(zé)寫 JSP，后端開發(fā)者負責(zé)寫 Controller 和 Model，然而在實際開發(fā)時還是有諸多問題。
首先業(yè)務(wù)邏輯依然沒有嚴格區(qū)分，如果沒有良好的編碼規(guī)范，JSP 中就會混入大量業(yè)務(wù)邏輯。而一個框架存在的作用應(yīng)該是讓沒有接受很多培訓(xùn)的新人也能寫出合格的代碼。此外，前端開發(fā)者還需要對后端邏輯有大致的了解，熟悉后端編程語言，因此也存在很多溝通、學(xué)習(xí)成本。
6 前端只寫Demo
一種解決方案是前端開發(fā)者只寫 Demo，也就是提供靜態(tài)的 HTML 效果給后端開發(fā)者，由后端開發(fā)者去完成視圖層(比如 JSP)的開發(fā)。這樣前端開發(fā)者就完全不需要了解后端知識了。
可惜這種想法很好，但是一旦付諸實現(xiàn)就會遇到不少問題。首先后端開發(fā)者依賴于前端的 Demo，只有看到 HTML 文件他們才可以開始實現(xiàn) View 層。而前端又依賴于后端開發(fā)者完成整體的開發(fā)，才能通過網(wǎng)絡(luò)訪問來檢查最終的效果，否則他們無法獲取真實的數(shù)據(jù)。
更糟糕的是，一旦需求發(fā)生變動，上述流程還需要重新走一遍，前后端的交流依舊無法避免。概況來說就是前后端對接成本太高。
舉個例子，在開發(fā) App 的時候，你的同事給你發(fā)來一段代碼，其中是一個本地寫死的視圖，然后告訴你:“這個按鈕的文字要從數(shù)據(jù)庫，那個圖片的內(nèi)容要通過網(wǎng)絡(luò)請求獲取，你把代碼改造一下吧?！薄Ｓ谑悄慊税胩鞎r間改好了代碼，PM 跑來告訴你按鈕文字寫死就好，但是背景顏色要從數(shù)據(jù)庫讀取，另外，再加一個按鈕吧。WTF？
顯然這種開發(fā)流程效率極低，難以接受。
7 HTMl模板
其實一定程度上來說，JSP 可以看做 HTML 模板的雛形。HTML 大體上肩負了兩個任務(wù): 頁面框架和內(nèi)容描述。所謂的 HTML 模板是指利用一種結(jié)構(gòu)化的語法，表示出 HTML 的框架，同時把具體數(shù)據(jù)抽離出來。
比如 <p>111</p> 表示一個段落，其中內(nèi)容為 “111”。如果用模板來表示，可以寫作 <p>Content</p> 或者 p Content 等等?？傊灰m結(jié)于具體語法，我們只要知道:
數(shù)據(jù) 模板 = HTML 源碼
比如在 Controller 層，可以這樣調(diào)用:
// 這里沒有指定模板的名稱，是因為使用了依賴倒置的思想，在配置文件中綁定了 Controller 對應(yīng)的 View
return res.view({title: '111'});
模板中的代碼如下:
<h1><%= Content%></h1>
熟悉前端開發(fā)的讀者可能會發(fā)現(xiàn)，這其實采用了 Sails.js EJS 開發(fā)。前者是基于 JavaScript 的服務(wù)端應(yīng)用程序，后者是基于 HTML 語法的模板，另一種風(fēng)格的模板是 Jade，不過本文的目的并不是重點介紹這些工具如何使用，就不再贅述了。
回到模板的概念上來，它相對于 JSP 的優(yōu)勢在于，利用工具強行禁止前端開發(fā)者在視圖層寫業(yè)務(wù)邏輯。前端開發(fā)者只需要關(guān)心 UI 實現(xiàn)并確定 HTML 中的變量。而后端開發(fā)者只要傳入?yún)?shù)即可獲取 HTML 格式的字符串。
模板開發(fā)的另一個好處是前后端可以同步開發(fā)。雙方約定一個數(shù)據(jù)格式，前端就可以模擬出假數(shù)據(jù)并用來自測，后端也可以用生成的數(shù)據(jù)與假數(shù)據(jù)對比進行測試。同時，這個約定的數(shù)據(jù)格式扮演了契約和文檔的作用，規(guī)范了雙方的數(shù)據(jù)交流形式，從而節(jié)省交流的時間成本。關(guān)于更多 Mock Server 的話題，請參考 這個連接。
8 后端MVC架構(gòu)總結(jié)
使用后端 MVC 架構(gòu)加上模板開發(fā)是當前比較主流的一種開發(fā)模型，但它也不是完美的。由于模板由前端開發(fā)者完成，所以要求前端開發(fā)者對后端環(huán)境(注意這里不是實現(xiàn)細節(jié))有所了解。
舉個簡單例子，大型應(yīng)用的后端要分很多文件夾，這就要求前端對代碼組織結(jié)構(gòu)有所了解，上傳文件時需要掌握 ssh、vim 并且依賴于服務(wù)端環(huán)境。
總的來說，采用服務(wù)端 MVC 方案時，HTML 在后端渲染，整體開發(fā)流程也全部基于后端環(huán)境。因此前端工程師不可避免的需要依賴于后端(雖然使用模板后情況已經(jīng)大大改善)。
9 AJAX與前端MVC
AJAX 的全稱是 Asynchronous Javascript And XML，即 “異步 JavaScript 和 XML”。它并非一個框架，而是一種編程思想。它利用 JavaScript 異步發(fā)起請求，結(jié)果以 XML 格式返回，隨后 JavaScript 可以根據(jù)返回結(jié)果局部操作 DOM。
AJAX 最大的優(yōu)點是不用重新加載全部數(shù)據(jù)，而是只要獲取改動的內(nèi)容即可。這在移動端編程中看上去是天經(jīng)地義的，而前端開發(fā)則需要專門使用 AJAX 來實現(xiàn)，默認情況下網(wǎng)頁的任何一處微小改動都需要重新加載整個網(wǎng)頁。
類比移動應(yīng)用就會發(fā)現(xiàn)，AJAX 適合做單頁面更新，但是不擅長頁面跳轉(zhuǎn)，就像你的 app 頁面跳轉(zhuǎn)都是新建一個 UIViewController/Activity 而不是直接把當前頁面的內(nèi)容全部換掉。
得益于 AJAX 的提出，HTML 在前端渲染變成了可能。我們可以下載一個空殼 HTML 文件和一個 JavaScript 腳本，然后在 JavaScript 腳本中獲取數(shù)據(jù)，為 DOM 添加節(jié)點。
這時候就出現(xiàn)了很多前端的 MVC 框架，比如 Backbone.js，AngularJS(姑且認為MVVM 是 MVC 的變種) 等一堆名詞，你可以從 這里 找到他們各自的 Demo。以我相對熟悉的 React 為例:
（上下滑動看代碼）
<!DOCTYPE html>
<html>
<head>
<script src='../build/react.js'></script>
<script src='../build/react-dom.js'></script>
<script src='../build/browser.min.js'></script>
</head>
<body>
<div id='example'></div>
<script type='text/babel'>
var LikeButton = React.createClass({
getInitialState: function() {
return {liked: false};
},
handleClick: function(event) {
this.setState({liked: !this.state.liked});
},
render: function() {
var text = this.state.liked ? 'like' : 'haven\'t liked';
return (
<p onClick={this.handleClick}>
You {text} this. Click to toggle.
</p>
);
}
});
ReactDOM.render(
<LikeButton />,
document.getElementById('example')
);
</script>
</body>
</html>
這段代碼不用完全讀懂，你只要意識到，引入 React.js 這個框架后，我們就可以脫離 HTML 編程了。所有的邏輯都寫在 <script> 標簽塊中的 JavaScript 代碼中。
我們還創(chuàng)建了一個 LikeButton 組件，它可以擁有自己的方法，管理自己的狀態(tài)等等。這里舉 React 的例子可能略有不妥，因為它其實只是一個 View 層的實現(xiàn)方案，還需要配合 Flux 或 Redux 架構(gòu)。不過也足以感受一下純 JavaScript 開發(fā)的感覺了。
這種開發(fā)模式和移動端開發(fā)非常類似，使用 JavaScript 調(diào)用 DOM 接口來繪制視圖，使用 JavaScript 來實現(xiàn)業(yè)務(wù)邏輯，處理數(shù)據(jù)，發(fā)起網(wǎng)絡(luò)請求等。你完全可以理解為單純用 JavaScript 在瀏覽器上開發(fā)移動應(yīng)用，只不過用戶下載的是 JavaScript 腳本而非傳統(tǒng)靜態(tài)語言編譯后的二進制文件。
使用了前端 MVC 框架后，對于單頁應(yīng)用(Single Page Application)來說，前后端各司其職，唯一的聯(lián)系就變成了 API 調(diào)用，前端開發(fā)者不再依賴后端環(huán)境，HTML 和 JavaScript 都可以放在 CDN 服務(wù)器上。這就是我們常說的 前后端分離 的基本概念，即前端負責(zé)展現(xiàn)，后端負責(zé)數(shù)據(jù)輸出。
10 前后端分離的缺點
然而在我看來，上述前后端分離方案遠遠遜色于后端 MVC 模板的開發(fā)流程，這是因為在實際開發(fā)中，純 SPA 的場景并不多見，即使移動端也不是只有一個視圖，而是有很多頁面跳轉(zhuǎn)邏輯，更何況到處都是超鏈接的網(wǎng)頁呢？
我們來看看在 SPA 和多頁面跳轉(zhuǎn)并存的情況下，采用前端 MVC 框架進行前后端分離存在哪些不足。
11 雙端MVC不統(tǒng)一
前端的 MVC 主要處理單個頁面內(nèi)的邏輯，而后端 MVC 框架處理的是整個 Web 服務(wù)器的邏輯。借用 jsconf 大會 上 赫門 的圖片來表示:
由于前后端 MVC 框架關(guān)注的重點不同，它們的地位自然也不同。前端的 MVC 框架負責(zé)頁面展示，因此它只是后端 MVC 框架的 View 層(或許只是一部分 View)。
這就會導(dǎo)致如下問題:
前端的 Model 和后端的 Model 結(jié)構(gòu)上高度類似，比如前端用到一個 name 屬性，后端也得在 JavaBean 中定義一個 name。有時候為了避免前端對數(shù)據(jù)做太多邏輯處理從而導(dǎo)致性能下降，后端可能已經(jīng)做了一些預(yù)處理。這就好比我們寫 App 時，拿到的 feed 流可能是篩選、排序過的，而我們在移動端還要在 ViewModel 中做一些轉(zhuǎn)化才能給 View 使用。因此，前后端邏輯上的耦合還是無法完全避免。
前端的 Controller 負責(zé)頁面調(diào)度，比如控件的狀態(tài)管理和樣式改變等。而后端的 Controller 負責(zé)調(diào)用服務(wù)，用戶鑒權(quán)等。兩者完全不等價。
前端也有路由模塊，它主要負責(zé)頁面內(nèi)控件之間的跳轉(zhuǎn)，比如 React-Router，而后端路由則是把不同的網(wǎng)絡(luò)請求分發(fā)給指定的 Controller。兩者邏輯也無法統(tǒng)一。
12 SEO
SEO(搜索引擎優(yōu)化)是一個移動開發(fā)者從來不考慮，但前端開發(fā)者視作生命的問題。搜索引擎的工作原理是訪問每個網(wǎng)頁，然后分析 HTML 中的標簽和關(guān)鍵字并做記錄。
一個純異步的網(wǎng)頁，HTML 幾乎是空殼子，而偏偏關(guān)鍵的數(shù)據(jù)都是動態(tài)下發(fā)的，這就影響了搜索引擎爬蟲的工作過程，他們會認為該網(wǎng)頁什么都沒有，即使記錄下來的也是非關(guān)鍵數(shù)據(jù)。
早些年谷歌推出了 Hash-bang 協(xié)議 來彌補 AJAX 對 SEO 造成的負面影響，它的本質(zhì)是為爬蟲提供后端渲染的降級處理機制。目前谷歌的爬蟲一定程度上可以閱讀 JavaScript 代碼并爬取相關(guān)數(shù)據(jù)，但 AJAX 在對爬蟲的支持上終究不如 HTML 文本直接傳輸。
13 性能不夠
從上文中 React 的示范代碼可以看出，HTML 文件非常小，很快就被打開。但是頁面的渲染邏輯直到 JavaScript 文件被下載后才能開始執(zhí)行，這就會導(dǎo)致一段時間的白屏。
在移動網(wǎng)絡(luò)上，前端渲染 HTML 的性能當然不如后端渲染，頻繁發(fā)送 HTTP 請求也會影響加載體驗，因此依賴于前端渲染的頁面，在性能方面還有很大的提高空間。
14 集中 Or 分離
很多年前，JavaScript 和 CSS 并不用單獨寫在外部文件中，而是直接內(nèi)嵌在 HTML 代碼里:
<p style='background-color:green'
onclick='javascript:myFunction()'>
This is a paragraph.
</p>
為了便于管理和修改，我們把 CSS 和 JavaScript 分離出來。然而到了 React 中，好像走了回頭路，所有邏輯都放在 JavaScript 中。
我的理解是，這種做法適合組件化，我們很容易定義出一個組件并且重用。這種思想對于復(fù)雜的 SPA 來說或許適用，但對于并不復(fù)雜但有多個頁面的網(wǎng)頁來說，就顯得太重了。引入了 React 這樣的框架，以及 MVC 的結(jié)構(gòu)，反而會顯得過度設(shè)計，增加代碼量和復(fù)雜度。
考慮到之前所說的前后端邏輯不能復(fù)用的問題，這就更容易導(dǎo)致性能問題。
15 Node.js
前后端分離的哲學(xué)
至此，我們已經(jīng)嘗試過后端 MVC 架構(gòu)，HTML 模板，前端 MVC 架構(gòu)等多種方案，但結(jié)果總是難以令人滿意，是時候總結(jié)原因了。
我們在進行上述實踐的過程中，過度強調(diào)物理層上的前后端分離，但是忽略了兩者天然就存在一定的耦合。實際上，前端開發(fā)者不僅關(guān)注 View 的實現(xiàn)，還應(yīng)該負責(zé)一部分 Controller 中的邏輯，后端開發(fā)者則應(yīng)該關(guān)心數(shù)據(jù)獲取與處理，以及一些跨終端的業(yè)務(wù)邏輯。
如果頁面渲染在后端實現(xiàn)，會導(dǎo)致前端開發(fā)者依賴后端實現(xiàn)和開發(fā)環(huán)境，后端開發(fā)者被迫熟悉前端邏輯(此時不是調(diào)用 API 而是直接生成數(shù)據(jù)并套用模板，這就要求把獲取的數(shù)據(jù)轉(zhuǎn)換成模板需要的數(shù)據(jù))。
如果頁面渲染全部放在前端，業(yè)務(wù)邏輯就會太靠前，從而導(dǎo)致不能復(fù)用。這種做法似乎有些矯枉過正了。此外，上文中也介紹了不少 AJAX 的缺點，就不贅述了。
我們似乎陷入了兩難的境地，頁面渲染不管是放在前端還是后端都不合適。其實這很好理解，頁面渲染涉及數(shù)據(jù)邏輯和 UI，他們理應(yīng)分別由前后端開發(fā)者分別負責(zé)，單獨交給任何一方都顯得不合適。
但如果前端工程師可以寫后端代碼，問題不就迎刃而解了么？實際上數(shù)據(jù)的處理可以分為兩個步驟:從數(shù)據(jù)庫或第三方服務(wù)獲取數(shù)據(jù)，把數(shù)據(jù)轉(zhuǎn)化為 View 可用的形式。前者往往和 C /Java 服務(wù)器相關(guān)，后者則和前端模板相關(guān)，它的作用更像是 MVVM 架構(gòu)中的 ViewModel。
Node.js 分層
我在上一篇文章中初步介紹了 Node.js 的定位:“一個用 JavaScript 進行開發(fā)的后端應(yīng)用程序框架”。因此它恰好可以完美的解決前端不了解后端邏輯和代碼的問題。
Node.js 作為一個中間層，調(diào)用上游 Java 服務(wù)器提供的服務(wù)，獲取數(shù)據(jù)。自身負責(zé)處理業(yè)務(wù)邏輯，路由請求，cookie 讀寫，頁面渲染等。前端則負責(zé)應(yīng)用 CSS 樣式和 JavaScript 交互，類似于最早期原始的模型。
借用 玉伯的 Web研發(fā)模式演變 中的圖片來說明:
node.js 中間層
16 實戰(zhàn)應(yīng)用
這不是一篇介紹 Node.js 的文章，我也不熟悉相關(guān)框架的應(yīng)用，舉這個例子是為了演示 Node.js 是如何做前后端分離的。
我選擇了 Sails.js 框架，項目的代碼在 Github: sails-react-example，這里簡單的分析一下。
視圖都放在 views 目錄下，采用 EJS 為模板，由 Node.js 負責(zé)在服務(wù)端渲染:
（上下滑動看代碼）
<div class='container'>
<h1><%= __('Comment') %>s for SAILS<small>js</small> REACT<small>js</small></h1>
</div>
<script src='/js/commentMain.js'></script>
Controllers 負責(zé)頁面轉(zhuǎn)發(fā)與模板渲染，具體的服務(wù)轉(zhuǎn)交給 Services 去完成:
module.exports = {
app : function(req, res) {
// 如果有必要，在這里調(diào)用 Services 獲取數(shù)據(jù)
return res.view({});
},
};
這個 Demo 中沒有實現(xiàn) Services，通常它用于和真正的后端進行交互，可以視情況選擇 HTTP 或 SOAP，并對返回結(jié)果做處理。此外還有 policies/responses 模塊分別對 HTTP 請求和返回內(nèi)容做處理。
前端的相關(guān)代碼都封裝在模板層，能夠與 Node.js 無縫接合。
17 風(fēng)險控制
雖然我們用增加 Node.js 處理層的方式解決了前后端分離中的一些痛點，但在實際應(yīng)用中還是需要考慮得更加周全。
新增一層后，勢必會導(dǎo)致性能損耗。然而分層本就是一個在衡量得失后做出的權(quán)衡，可以通過各種優(yōu)化把性能損耗降到最低。況且，在 Node.js 這一層還可以使用 BigPipe 來處理多個異步請求。
傳統(tǒng)網(wǎng)頁在加載頁面時，首先獲取 HTML，然后獲取其中引用的 CSS 和 JavaScript。在服務(wù)端準備數(shù)據(jù)和網(wǎng)絡(luò)傳輸過程中，瀏覽器需要一直等待，而 BigPipe 將頁面分成若干小塊，雖然每個塊的加載邏輯不變，但塊與塊之間可以形成流水線作業(yè)，避免瀏覽器無意義的等待。
使用 BigPipe 技術(shù)在一定場景下可以代替 Ajax 的多個異步請求。具體介紹可以參考 BigPipe學(xué)習(xí)研究。
使用 Node.js 后，對前端開發(fā)者的技術(shù)要求提高了，編碼工作量也會相應(yīng)的增加。然而這都是工程化的必經(jīng)之路，編碼量增加的背后其實是溝通、維護效率的提高。
18 總結(jié)
為了處理前后端復(fù)雜的邏輯，我們嘗試了使用了后端 MVC 框架來分離業(yè)務(wù)，用 HTML 模板來分離數(shù)據(jù)和 UI 樣式。使用了 Ajax 技術(shù)的網(wǎng)頁更適合單頁應(yīng)用，雖然做到了物理層的分離，但在處理多頁面時還是有不少問題。
實際上頁面渲染本就是前后端共同關(guān)心的話題，我們更應(yīng)該根據(jù)業(yè)務(wù)邏輯進行前后端分離。最終選擇了 Node.js，借助它使用 JavaScript 的特性，由前端工程師負責(zé)獲取數(shù)據(jù)后的處理和模板的使用，分擔(dān)了一部分原本邏輯上屬于前端，但技術(shù)上偏向后端的任務(wù)。這種開發(fā)模式看上去像是一種倒退，其實是螺旋式的上升與返璞歸真。
Node.js 基于事件和異步 I/O 的特性，以及優(yōu)秀的處理高并發(fā)的能力非常適合前后端分離的場景，使用 BigPipe 等技術(shù)也足以將分層帶來的損耗降到最低。選擇 Node.js 做前后端分離并不一定最佳實踐，但在目前看來有不錯的應(yīng)用，同時也需要一邊探索一邊前進。
作者：bestswifter
