爲什麼要做前後分離？
可以這樣去理解何謂前後分離，它其實是展現端和數據服務的分離。
這裏第一件要做的事情就是服務端純數據接口化改造，爲什麼要做這件事情呢？因爲多端時代已經來臨，一項數據可能需要以不同的樣子展現在PC瀏覽器中、移動瀏覽器中以及移動App中。服務端的純數據接口可以同時爲多展現端服務，這顯然可以提高研發效率。
前後分離的另一個好處就是讓前後端工程師的職責更加明晰，除了單一數據源多展現端支撐之外，好的前後端分離架構還必須具備前後端基於接口定義獨立並行開發，前後端獨立發佈等能力。
今天討論的內容大綱
在過去的幾年，以Backbone爲代表的OPOA（One Page One Application）解決方案盛行。而如今，使用Node在服務端負責展現層的架構亦漸起燎原之勢。那麼後者對於前者到底是進化、革新，還是面向不同場景的不同架構？是今天突然想寫篇文章來八一八的內容：
- 前後分離最徹底的方案是OPOA
- OPOA適合什麼場景又有什麼問題
- 多端時代OPOA依然需要進化
- Node負責展現層的“前後分離”方案又是什麼
- 如何看待Node在其中的位置
前後分離最徹底的方案是OPOA
OPOA的架構示意圖如上，如果我們單看一個邏輯頁面（一個時間點瀏覽器中的全部內容），分析一下有幾個特點：
- 頁面完全由前端構建拼裝，Backbone等框架的任務是把頁面中的視圖排排好
- 多數情況由視圖來發起其所需的數據請求，所以會有多個Ajax請求或並行、或串行的發生
- 服務端的數據接口提供獨立的http服務。
爲什麼說OPOA是最徹底的前後分離方案？首先，這裏的分離是瀏覽器端和服務端的真正分離，跟“前”與“後”這個說法更貼近：）；當然更主要是前後端的在物理位置上的鴻溝，客觀要求服務端純數據接口化的改造必須進行的徹徹底底；此外，“徹底”還表現在：OPOA額外的好處是對前端性能有幫助，複雜交互組件所需的JS和模板，無需重複加載、運行，給系統易用性帶來幫助。
OPOA適合什麼場景又有什麼問題
OPOA更適合一個頁面不太多，但交互複雜的系統。如果系統中的衆多頁面長的根本不一樣，多頁面間也沒有太多重複的組件，那麼OPOA帶來的性能提升就很小了。而且OPOA架構本身也有着難以解決的問題：
- OPOA最大的問題是搜索引擎不友好，雖然已有多種爲Spider提供內容的方案，但依然對SEO有傷害，這對很多網站而言是致命的。
- OPOA中複雜頁面，往往請求數較多，在PC端沒有問題，但對於移動端而言就不那麼美觀了。
多端時代OPOA依然需要進化
拋開SEO不談，在多端時代，OPOA依然需要進一步進化，目標是來解決請求數較多的問題。
如上圖所示，我們要做的是“動態數據的Combo”（這樣說，是方便大家對比常見的靜態JS、CSS的Combo），即：
- 前端：我們需要一個動態請求管理器，將多個請求集中起來，發送給後臺服務。
- 後端：我們需要一個請求分解到多個子服務，再將多個子服務返回的數據Combo後返回。
Node負責展現層的“前後分離”方案又是什麼
在上上小節我們分析過，如果一個系統多個頁面之間並沒有太多重合，頁面間沒有太多需共用的複雜的交互組件，那麼OPOA就不是必須的。這時候我們還能不能做到前後分離呢？我們回到前後分離的初衷：
- 單一數據源多展現端支撐
- 前後端基於接口定義獨立並行開發
- 前後端獨立發佈
我們基於上一張圖，而不是OPOA之前的傳統網頁架構去理解所謂“Node負責展現層”相關技術方案，會更容易循序漸進的發現它的實質。
無論哪種標榜“前後分離”架構服務端純數據接口化的改造都是必須的，我們做到這一點之後，在使用Node負責展現層的架構中，就還有兩個任務需要完成：
- Action1：將動態請求Combo的相關邏輯，用Node實現，包括頁面多數據區塊對於數據需求的統一管理，以及統一獲取。
- Action2：將Backbone等前端OPOA框架中對於路由、視圖的管理移植到Node中。
做完這兩項任務之後，在瀏覽器端的表象上，網頁從單頁應用的Web Application迴歸到傳統的多頁Web Page模式。但是通過良好的設計，我們依然可以拿到做“前後分離”最想要的那些好處。
本文總結，以及如何看待Node在其中的位置
在多端時代，服務端純數據接口化改造是大勢所趨，這客觀上給“前後分離”提供了更大的舞臺。一個傳統多頁型網頁系統在完成服務端接口化改造之後，需要做的事情有兩個：統一管理構成一個頁面的所有數據需求，完成頁面拼裝並輸出。
而單就這兩個任務而言，Node應該說不是必須的。Node的異步特性，高併發能力都不足以成爲其在服務端多語言競爭的環境裏獲勝的核心優勢。
我認爲引入Node的優勢有兩個：
- 促進前後端更好的分離，就像CSS出現之後，我們不再用<font>標籤定義文字樣式一般，引入不同的技術、不同的語言可以讓每個模塊所承擔的職責更加界線清晰，進而讓服務端純接口化改造更徹底、更堅定。“前”與“後”在服務端進行分離，OPOA中瀏覽器與服務端在物理位置上的鴻溝不再存在，那麼新的語言和技術是劃分邊界這一任務的繼承者。
- 促成前端工程師和後端工程師在開發時的解耦，面對明晰的接口定義，前端工程師可以和後端工程師並行無交集的開發，直到最後階段聯調。這可以帶來研發效率上的極大提升。
“天下武功、唯快不破”，無論是做徹徹底底的OPOA，還是用Node做展現層服務，它們所帶來的研發效率方面的提升纔是架構革新的源動力。
對於前端工程師而言，還需戒躁戒躁吧，用了Node不等於“高、大、上”，我們切換至服務端做的事情與一個良好的“Backbone”類框架沒有太多本質的區別。而在前後分離之後，前端承擔的職責無疑更重了，過往我們開發完Demo就可以撒手不管的情況不再存在。特別是介入服務端研發之後，線上故障、穩定性、安全性這些過往和前端不太挨邊兒的令人惶恐的東東都會不期而至，我感覺前端們還沒做好準備，常常都是經歷過了纔有切身的體會，纔會成長吧。