最近這幾年，隨著軟硬件技術的發(fā)展，Web開發(fā)的相關技術也在突飛猛進，跟十年之前甚至五年之前相比，無論是業(yè)務復雜度還是技術選型已經(jīng)完全是兩個維度。

本文是一篇隨筆，主要闡述一些作者個人對web開發(fā)模式的一些認知和思考。

前言

在五、六年前，或者更早的時候，當談及Web開發(fā)的時候，更多的是指代某一種以后端語言為主的技術棧，比如Java Web，Ruby on Rails，Php等技術棧。經(jīng)過最近幾年的web開發(fā)相關技術的迅速發(fā)展，現(xiàn)在說web開發(fā)可能會在不同的場景下會有不同的劃分。

典型的，所謂的Web前端、Web全棧等最近幾年才被逐漸細分出來的技術方向，正是在前面這種大環(huán)境下產(chǎn)生的。

言歸正傳，我們說Web開發(fā)，那么什么Web開發(fā)？Web開發(fā)的本質(zhì)是什么？

如果在一個比較高的抽象層面來看這個問題，Web開發(fā)就是處理客戶端請求及服務端響應這兩件事。

上圖就是一個非常高的級別的抽象。實際的開發(fā)中，還會有許多方面是需要考慮的。

我們來稍微豐滿一下這個抽象。

大概2008年左右，一個web應用或者web開發(fā)的標準模型如下圖，

此時，后端主要做的事情是從數(shù)據(jù)庫中拉取數(shù)據(jù)，在server端生成html模板，然后將生成的模板發(fā)送到客戶端?？蛻舳耸盏侥０搴螅诳蛻舳俗⑷雑s和css，生成dom樹，然后渲染成頁面呈現(xiàn)給用戶。

這種模式現(xiàn)在依然在某些web應用的開發(fā)中被使用。這種模式現(xiàn)在更多的被稱之為傳統(tǒng)開發(fā)模式，或者前后端混合開發(fā)模式。其主要的一個特點是，頁面模板由后端吐出，甚至吐出的模板會帶有樣式和交互。前端僅僅是將模板丟給瀏覽器渲染成dom樹生成頁面而已。有時候，前端也會注入一些js代碼為頁面的動態(tài)交互提供支持。

這種開發(fā)模式，我本人是實際經(jīng)歷過的。以前JavaEE、JavaWeb比較火的時候，經(jīng)常會寫一個某某系統(tǒng)，比如學生管理系統(tǒng)、圖書管理系統(tǒng)之類的，在server端通過java來操作JDBC鏈接數(shù)據(jù)庫，拿到需要的數(shù)據(jù)，然后將數(shù)據(jù)與jsp組裝起來一起發(fā)送給客戶端，客戶端再交給瀏覽器渲染。后來還經(jīng)歷過php加smarty的開發(fā)模式。其實這兩種雖然使用的是不同的技術棧，但是開發(fā)模式的本質(zhì)是一樣的。

但是，這時候我們會發(fā)現(xiàn)，同一個開發(fā)者會扮演好幾種角色，需要寫server端代碼，同時也需要寫模板層代碼，甚至還會寫一些js和css代碼。這里需要開發(fā)者在不同角色中切換。但是專注server端的開發(fā)者們往往非常討厭或者說不擅長寫模板、交互和樣式，這時候又發(fā)展出一種所謂套頁面的開發(fā)模式。所謂套頁面，是指先讓專職的前端開發(fā)切好靜態(tài)頁面，然后丟給后端開發(fā)去模仿然后寫出模板，將需要動態(tài)變化的地方換成后端模板語法。這種模式已經(jīng)被證明是低效的，而且并沒有合理的應用開發(fā)資源。

說到開發(fā)效率，在一個大體量的團隊協(xié)作中，我們應該秉承這樣一種思路，就是讓合適的人去合適的事，分工協(xié)作，流水線作業(yè)肯定是最優(yōu)的方案。

傳統(tǒng)開發(fā)模式下，我們的確有一些痛點需要解決。從而衍生出了這樣一種思路，讓前后端的開發(fā)分離開來，不同工種只負責各自的事情，然后遵循某一種協(xié)作約定，達到高效產(chǎn)出。

上面基本上就是前后端分離的演變歷史。

前后端分離的開發(fā)模式大概如下圖所示，

前后端分離開發(fā)模式下，server端從數(shù)據(jù)庫拿到元數(shù)據(jù)，經(jīng)過處理后直接吐出數(shù)據(jù)，而不是模板。client端拿數(shù)據(jù)之后，在客戶端端進行模板渲染生成頁面呈現(xiàn)給用戶。

相比傳統(tǒng)開發(fā)模式，此時服務端不再處理模板層的業(yè)務，而是直接只提供數(shù)據(jù)。職責更加單一。此時的服務端可能會根據(jù)不同業(yè)務需求或者架構差異，還可能會直接提供服務。這里服務的含義往往指代的是微服務。甚至在一些非絕對的前后端分離模式下，服務端還會提供模板片段。

顯而易見，此模式下，前端開發(fā)需要做更多的事，而且可能會隨著業(yè)務的增長前端邏輯和代碼量會越來越龐大和復雜。這又推動了各種前端框架的涌現(xiàn)，比如Angular這種大而全的框架，比如React這種專注解決某一個層面業(yè)務的框架，比如Webpack這種彌補構建功能缺失的框架，等等。各種框架本身又會帶動其周邊社區(qū)的發(fā)展，使得整體前端開發(fā)圈子呈現(xiàn)技術爆炸式的發(fā)展。

除了傳統(tǒng)Web開發(fā)之外，因為移動互聯(lián)網(wǎng)的快速發(fā)展，移動端開發(fā)、微信開發(fā)、h5開發(fā)等等范疇，也被前端開發(fā)者們照單全收。還有，由于NodeJS平臺的崛起，前端開發(fā)可能已經(jīng)不僅僅限于瀏覽器端的開發(fā)工作，借助NodeJS平臺，以及Express、Koa等框架，前端開發(fā)者已經(jīng)具備了涉足服務端開發(fā)的能力。

這里有一篇文章，足以管中窺豹，前端開發(fā)的技術棧廣度和更新速度。

所以，可以探討的內(nèi)容實在是非常的多，本文不會過度發(fā)散，僅僅是探討Web開發(fā)相關的內(nèi)容。下面會將重心放在pc端的web開發(fā)模式的探討上，以前后端分離為出發(fā)點，闡述本人經(jīng)歷過的兩種開發(fā)模式，以拋磚引玉。

中間層模式

前面有說過，因為NodeJS平臺的活躍，特別是一些成熟的服務端開發(fā)框架的出現(xiàn)，比如express、koa等，讓前端開發(fā)者使用javascript進行服務端程序的開發(fā)成為可能，甚至還可以操作數(shù)據(jù)庫。這也給之前一直在瀏覽器端開發(fā)的前端開發(fā)者們開辟了新的工作場景，如果再掌握一些數(shù)據(jù)庫，http協(xié)議，網(wǎng)絡安全，web server等方面的知識，那么我個人感覺前端開發(fā)者完全可以將自己的角色切換成一名后端開發(fā)，處理一些通用場景下的后端開發(fā)應該是沒有問題的。

顯而易見，這對傳統(tǒng)的前端開發(fā)者們提出了更高的要求，工作內(nèi)容涉足的領域相比之前而言更加底層，會更加頻繁的去和真正的后臺開發(fā)者進行溝通，甚至會參與一些約定和規(guī)范的制定，這時候又會要求我們能夠有一些后端思維，否則你跟別人在溝通事情的時候都不在頻道上，那怎么可以呢？！

這部分內(nèi)容的標題是中間層模式，那么什么是中間層模式呢？我個人的理解是，以前后端分離為出發(fā)點，借助NodeJS平臺，在web后端與傳統(tǒng)前端（UI層）之間增加一層中間層，負責處理數(shù)據(jù)、模板、業(yè)務等內(nèi)容。它是后端與UI層的橋梁。有的人喜歡稱這個中間層為膠水層。

下面有一張我自己畫的圖，我覺得應該可以表達出我想法中的所謂中間層模式，

1. 首先，這里可能沒有明確意義上的后端，取而代之是REST Server、Micro Service等內(nèi)容。他們的本質(zhì)依然是對上層提供數(shù)據(jù)。這些內(nèi)容都屬于backend的范疇。
2. backend的上層就是frontend。這里所謂的frontend其實是一種寬泛的指代，它表示了一個響應用戶請求、交互等操作的集合。在這個集合中，最上層是用戶，然后是客戶端（瀏覽器）層，然后客戶端的的下面是NodeJS層。此外還會有一個nginx層。
3. 第一種場景，當用戶發(fā)起一個頁面請求時，瀏覽端會首先接受這個請求，然后丟給nginx來代理，nginx根據(jù)請求的類型將請求轉發(fā)給對應的NodeJS層服務。NodeJS層內(nèi)部會解析來自nginx層轉發(fā)的請求，執(zhí)行對應的業(yè)務類，組裝數(shù)據(jù)，最終輸出一個html模板給客戶端（瀏覽器），瀏覽器端拿到模板之后，注入客戶端的js和css代碼之后再渲染到成頁面，呈現(xiàn)給用戶。
4. 第二種場景，用戶在頁面發(fā)起交互請求時，比如點擊按鈕發(fā)起請求，此時這個請求最終會丟給NodeJS層，NodeJS層收到請求之后進行處理，然后將響應返回給瀏覽器。
5. 基本上，絕大部分來自客戶端（UI層）的請求和交互都會在NodeJS層進行處理，UI層與底層的REST服務或者微服務是隔離的。當然也有特例，比如圖片驗證碼這種場景，將會由瀏覽器直接請求底層REST服務或者微服務。比如，
6. 很多時候，用戶通過url請求一個頁面時，NodeJS層收到這個請求后，會同時發(fā)出多個REST請求，或者向多個微服務發(fā)出請求，待所有的REST請求都返回后，在NodeJS層進行數(shù)據(jù)組裝，處理，清洗等操作，這其中可能會摻雜一些特定的業(yè)務需求。我們一般稱這一過程為REST Combo。比如，

通過上面的描述，這種模式下前端開發(fā)們將會處理三方面的事，

1. nginx層，監(jiān)控請求及類型，轉發(fā)請求到對應的NodeJS服務。
2. UI層，瀏覽器端實現(xiàn)，各種交互、樣式、布局等。
3. NodeJS層，連接UI層和底層數(shù)據(jù)提供方的橋梁，同時可能會注入一些偶合具體業(yè)務的實現(xiàn)。

更進一步，我們在實際項目中，可以將UI層和NodeJS層不必劃分太明確的界限，如下的目錄結構，

其中app目錄是NodeJS層代碼，public目錄是UI層代碼，dist是項目構建之后的目錄。在項目部署時，只會針對dist目錄。

除此之外，這種模式下，我們還有許多可以探索和嘗試的地方，比如

1. UI層實現(xiàn)的技術選型其實是比較靈活的，可以用JQuery式的開發(fā)方式，也可以引入一些成熟的前端MV*框架（比如NG，React，VueJS等）來提升開發(fā)效率。引入這些框架之后，可能會帶來許多其他層面需要解決的問題，比如前端構建、前端模塊化等等。
2. NodeJS可以不吐出模板，而是直接吐出數(shù)據(jù)或者吐出模板片段和數(shù)據(jù)。將NodeJS當成UI層的數(shù)據(jù)提供server。
3. 共用UI層和NodeJS層的部分代碼，比如特定的業(yè)務代碼，邏輯判斷，表單校驗等等。
4. 可以將NodeJS層和UI層隔離構建打包，也可以混合構建打包。
5. ……

中間層模式解決方案的實踐

這里我嘗試給一個中間層模式的解決方案sword-plus。它的定位并不是大而全的一站式解決方案，而是為了更便利的開發(fā)NodeJS層的一系列工具集合以及常用功能的提煉?；?a rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" target="_blank">Koa程序，提供了日志記錄、模板渲染、請求訪問、路由解析、業(yè)務類抽象等功能。其內(nèi)部的各個功能組件存在一定程度上的偶合。所以使用sword-plus的前提是，引入NodeJS作為中間層；底層的框架選型為Koa；NodeJS層向上層提供組裝好數(shù)據(jù)的模板。

sword-plus包括以下幾個部件，Router、Pugger、Connector、Logger、Handler、SwordError。

Router用于解析koa的包裝后的請求。其中有兩個主要方法，

1. parse，解析路由
2. provider，生成業(yè)務類，并啟動對應路由的業(yè)務邏輯

Pugger主要用于組裝數(shù)據(jù)并渲染Jade/Pug模板。

1. 這里的模板屬于服務端模板，在渲染的過程中，可通過參數(shù)配置是否記錄渲染日志。
2. 主要方法render，用于組裝數(shù)據(jù)生成服務端模板。
3. 渲染日志將會記錄在渲染過程中的任何報錯信息。

Connector封裝了NodeJS層->REST層，UI層->NodeJS層的請求操作。內(nèi)部使用了node-fetch。同時允許在操作請求時，記錄請求日志。它有兩個方法，

1. get，執(zhí)行get請求
2. post，執(zhí)行post請求

Logger是日志組件，Logger將所有的日志分為如下幾大類（category），

• fatal、error、warn、info
• request、response、render、action

其中第一行其實是bunyan自帶日志等級的alias，第二行是根據(jù)不同業(yè)務場景抽象出來的。

1. request，NodeJS程序向REST服務器發(fā)送rest api請求的日志
2. response，REST服務器返回給NodeJS程序的rest api響應的日志
3. render，服務端模板的渲染日志，這里所謂的渲染日志其實是跟客戶端（瀏覽器）是沒有關系的，它僅僅表示模板文件和數(shù)據(jù)的組裝和編譯過程
4. action，所有由用戶發(fā)起從而產(chǎn)生的交互日志，包括頁面請求、表單提交、客戶端ajax請求等等

每一條日志都是一個record抽象，每個record實例在category的維度下，還會有l(wèi)evel的區(qū)分，常用的level有如下幾種info、warn和error。

Handler是業(yè)務類模型的頂層抽象。所有請求經(jīng)過Router解析之后，都會通過Handler來派生出具體的業(yè)務類。在Handler中可以使用內(nèi)部擴展或者外部拓展(Handler.inject)，來增加所有業(yè)務類可使用的功能方法。此外，Handler中對幾個套件的實例對象做了代理，使得在具體的業(yè)務類中可以使用他們。Handler中提供如下幾個方法，

1. inherits，在Router解析完畢之后，在Router.provider中通過此方法生成具體的業(yè)務類Clazz。
2. dispatch，在業(yè)務類中對get和post請求類型進行自適配轉發(fā)。
3. inject，在server啟動時，可以根據(jù)需要注入外部拓展，一旦注入，則在所有生成的業(yè)務類中都可使用。

SwordError是SwordPlus的Error封裝。用于統(tǒng)一分配error。

目前SwordPlus Error的type有如下幾種，

• LACK_OF_PARAMETER
• INVALID_OF_PARAMETER
• 404
• ERROR_OF_MAKEDIR
• SUFFIX_NOT_SUPPORT
• SUFFIX_IS_REQUIRED
• TIMEOUT
• MODULE_NOT_FOUND
• NO_TEMPLATE_FILE

sword-plus的執(zhí)行流程簡圖大致如下，

具體的使用可以參考sword-plus中的demo文件夾。

完全分離模式

這里稍微提一下所謂的完全分離模式，即此模式下的前端開發(fā)和傳統(tǒng)意義上的后端開發(fā)完全隔離開，不會涉及到中間層的開發(fā)。如下圖，

此時，前端和后端通過ajax請求來交互，后端返回給前端數(shù)據(jù)?？蛻舳说乃惺虑椋撁驿秩?、交互、樣式、路由等等都是由前端自己來管理。此時前端開發(fā)往往會引入一個較為成熟的前端開源框架作為底層選型。這種開發(fā)模式有其獨特的適用場景，比如單頁應用（Single Page Application）、企業(yè)內(nèi)部的某個管理系統(tǒng)等等。如果前端開發(fā)對底層選型的框架較為熟悉，往往開發(fā)速度非常快，基本上在實際開發(fā)中遇到的一些問題都可以在框架社區(qū)中找到解決方案。

這種開發(fā)也有其短板的方面，往往隨著需求迭代，前端的代碼量會越來越多，前端的各種交互和模塊化管理會越來越重，越來越不好維護。還有一點就是可供選擇的方案非常多，有時候你會不知道到底選擇哪種方案好。

我個人的看法是，根據(jù)場景和需求來進行實現(xiàn)方案和技術的選型，不要一味的追求新技術和潮流。目前前端圈子中流行的幾種主流框架，比如Angular，React，Vue等都會有其優(yōu)勢和弱勢的地方。比如，Angular本身是包羅萬象的框架，一旦熟悉起來開發(fā)速度非?？?，但是其入門門檻低深入比較復雜，而且有一些場景是其先天不適合的。React只關注View層的處理，提供了一個非常好的思路告訴我們應該如何做View和Data層的交互和更新，但是其現(xiàn)有的數(shù)據(jù)狀態(tài)管理方案比如Redux，我個人感覺一直都不是太好用。VueJS的作者吸收了市面上眾多框架的優(yōu)勢，個人感覺它一直都在發(fā)展中，本人并沒有在生產(chǎn)環(huán)境中使用過，不作過多評價。

不過話說回來，個人認為前端圈子目前的快速發(fā)展是非常好的，雖然新東西很多，解決同一個痛點的方案可能會有很多選擇，但是這并不影響我們?nèi)W習他們，去領悟它們的解決問題的思維，甚至去體驗一下他們有坑的地方，至于到底要不要再生產(chǎn)環(huán)境使用，那是另外一回事了，所以我個人并不厭惡前端圈子的當下的這種現(xiàn)狀。

總結

這篇文章的主旨意在闡述一些我個人對當下web開發(fā)模式的認知和探索，個人認為文章中的中間層開發(fā)模式是一種萬金油的開發(fā)模式，除了文章中談到的內(nèi)容，我也給出了一些可供繼續(xù)探索下去的點，我認為中間層開發(fā)模式基本上可以適配任何需求下的web開發(fā)需求。