前后端協(xié)作之分離

前后端協(xié)作的三板斧，

• 第一斧：前后端協(xié)作之分離
• 第二斧：前后端協(xié)作之約定
• 第三斧：前后端協(xié)作之集成

前言

隨著Web開(kāi)發(fā)技術(shù)的更新?lián)Q代，特別是Web2.0、NodeJS等平臺(tái)或者概念的活躍，使得web開(kāi)發(fā)越來(lái)越多樣化，越來(lái)越靈活。最典型的一個(gè)特性就是，針對(duì)不同的業(yè)務(wù)場(chǎng)景，針對(duì)不同的需求、平臺(tái)等內(nèi)容，我們使用的技術(shù)棧會(huì)有所側(cè)重，不再是以前的那種一桿槍打天下了。

從大的層面上來(lái)說(shuō)，web開(kāi)發(fā)可以分為面向?yàn)g覽器的前端，以及面向服務(wù)端的后端。我個(gè)人一般習(xí)慣的將前端稱(chēng)之為瀏覽器端，主要是為了規(guī)避一些信息同步上的問(wèn)題，因?yàn)閷?duì)一些長(zhǎng)期從事C、C++之類(lèi)語(yǔ)言的底層開(kāi)發(fā)的人員來(lái)說(shuō)，除了底層，其他的都是前端。

web開(kāi)發(fā)這個(gè)技術(shù)方向發(fā)展了這么久，依然擺脫不了下面這種原型，

簡(jiǎn)單來(lái)說(shuō)，就是

1. client端向server端發(fā)送request
2. server處理來(lái)自client的請(qǐng)求，并返回response

原型非常簡(jiǎn)單，但是這僅僅是最基本的原理，其中有非常多的門(mén)道，實(shí)非一篇文章所能言盡。

耦合與分離

我剛畢業(yè)那會(huì)兒，大概6，7年之前吧，因?yàn)楦鞣N各樣的原因，Java語(yǔ)言開(kāi)始變得非常流行，當(dāng)時(shí)在學(xué)校里基本上可以隨處可見(jiàn)各種培訓(xùn)機(jī)構(gòu)，廣告吹得一個(gè)比一個(gè)厲害。那時(shí)候用Java來(lái)做web開(kāi)發(fā)，基本上都是J2EE，一個(gè)人寫(xiě)servlet，同時(shí)也寫(xiě)jsp，最后往tomcat上一丟就完事了。

這種模型是典型的耦合式開(kāi)發(fā)。所謂的耦合式開(kāi)發(fā)有兩個(gè)典型特點(diǎn)，一是同一種角色從前到后基本都寫(xiě)；二是基本上都是服務(wù)端模板、服務(wù)端渲染。

這種模式有如下幾個(gè)非常明顯的缺陷，

1. 同一個(gè)角色干了多個(gè)事情，要經(jīng)常切換思維場(chǎng)景，同是對(duì)開(kāi)發(fā)者也提出了更高的要求。
2. 不具備良好的拓展性和可維護(hù)性。
3. 往往會(huì)將一些新思想和新技術(shù)拒之門(mén)外，難以嘗試。

于是，人們便想出了一個(gè)法子，就是讓面向?yàn)g覽器的開(kāi)發(fā)者和面向服務(wù)端的開(kāi)發(fā)者分開(kāi)。前后分離思想從此一發(fā)不可收拾，許許多多的前輩們?cè)谶@條路上貢獻(xiàn)了自己的思考以及解決方案。

我個(gè)人認(rèn)為前后端分離的一個(gè)核心思想是：讓合適的人做合適的事，并在此基礎(chǔ)上持續(xù)探索在不同業(yè)務(wù)場(chǎng)景下的最優(yōu)開(kāi)發(fā)模式。

試想一下，假如現(xiàn)在我們要做一個(gè)項(xiàng)目，那么這個(gè)項(xiàng)目可能會(huì)有兩個(gè)工程，一個(gè)前端工程，一個(gè)后端工程。需求確認(rèn)完畢之后，前端開(kāi)發(fā)者和后端開(kāi)發(fā)者在一定的約定基礎(chǔ)上并行開(kāi)發(fā)，待開(kāi)發(fā)完畢之后，再通過(guò)某一種方式進(jìn)行集成即可。理想是美好的，但是現(xiàn)實(shí)卻不會(huì)那么順利，這中間有著許多的坑等著我們?nèi)ゲ取?/p>

在《Web開(kāi)發(fā)模式的探索與思考》這篇文章中，我也有提到過(guò)，目前有兩種主流的前后分離思路，一種是完全的前后分離模式，一種是中間層模式。這兩種模式我個(gè)人覺(jué)得沒(méi)有絕對(duì)的好與壞，兩者都有各自切合的場(chǎng)景。

不過(guò)我看過(guò)很多的前后分離開(kāi)發(fā)的網(wǎng)站，說(shuō)實(shí)話(huà)體驗(yàn)不是很好。我個(gè)人感覺(jué)可能是網(wǎng)站的開(kāi)發(fā)者走入了一個(gè)誤區(qū)，

• 其一，在不合適SPA的場(chǎng)景下強(qiáng)拼硬湊SPA模式，使得前端過(guò)重。
• 其二，前后端之間的數(shù)據(jù)交換過(guò)度依賴(lài)ajax。在一些數(shù)據(jù)模塊及交互復(fù)雜的頁(yè)面上，使得ajax數(shù)據(jù)交互成為瓶頸。
• 其三，前端的技術(shù)棧是那種完全的前后分離模式，有點(diǎn)一條道走到黑的感覺(jué)。網(wǎng)站開(kāi)發(fā)者們可能并沒(méi)有考慮不同業(yè)務(wù)場(chǎng)景下對(duì)不同開(kāi)發(fā)模式和技術(shù)棧的要求。
• 其四，可能是因?yàn)榍岸诉^(guò)重的原因，導(dǎo)致有一些非常明顯的糟糕的操作體驗(yàn)，比如加載性能，視覺(jué)等待，白屏過(guò)長(zhǎng)等等。

說(shuō)實(shí)話(huà)，在兩三年之前，我也是“完全前后分離”這一模式的鐵桿粉，當(dāng)時(shí)用AngularJS、ReactJS之類(lèi)的MV*框架，覺(jué)得基本上沒(méi)有什么事在前端范疇之內(nèi)是解決不了，后端只要有ajax接口，只要給我前端提供數(shù)據(jù)就行了。我相信很多前端開(kāi)發(fā)者現(xiàn)在依然有這種想法，而且可能還會(huì)覺(jué)得這么想是理所當(dāng)然。

如果開(kāi)發(fā)者把自己的眼界放遠(yuǎn)一點(diǎn)，不局限在前端這一范疇的話(huà)，你會(huì)發(fā)現(xiàn)除了前端這薄薄的一層之外，web開(kāi)發(fā)中還有非常多的內(nèi)容值得推敲的，只有站在更高的基點(diǎn)上，才能對(duì)整個(gè)web開(kāi)發(fā)的生命周期做整體把握。

探討

這里我先拋出一個(gè)問(wèn)題，然后會(huì)在最后一篇文章中分析在兩種主流的前后分離模式下如何做，以及它們的優(yōu)劣勢(shì)，最后會(huì)探討一下應(yīng)該怎么做。

問(wèn)題是這樣的，假設(shè)我需要做一個(gè)網(wǎng)站，這個(gè)網(wǎng)站會(huì)有類(lèi)似企業(yè)首頁(yè)那種偏資訊類(lèi)的頁(yè)面，然后會(huì)有用戶(hù)體系。用戶(hù)登錄后，會(huì)有一個(gè)管理中心的中控系統(tǒng)，這個(gè)管理中心中會(huì)按照功能劃分出好幾個(gè)功能模塊。管理中心的頁(yè)面會(huì)給用戶(hù)提供較多的交互操作。然后還有兩個(gè)額外需求，一個(gè)是各個(gè)功能模塊的頁(yè)面之間會(huì)有數(shù)據(jù)傳輸；另一個(gè)是各個(gè)頁(yè)面之間的跳轉(zhuǎn)能夠比較平滑，不要產(chǎn)生難以容忍的白屏。