Web開發模式的探索與思考

最近這幾年，隨著軟硬體技術的發展，Web開發的相關技術也在突飛猛進，跟十年之前甚至五年之前相比，無論是業務複雜度還是技術選型已經完全是兩個維度。

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

　　前言

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

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

　　言歸正傳，我們說Web開發，那麼什麼Web開發?Web開發的本質是什麼?

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

大概2008年左右，一個web應用或web開發的標準模型，後端主要做的事情是從資料庫中拉取數據，在server端產生html模板，然後將產生的模板送到客戶端。用戶端收到範本後，在客戶端注入js和css，產生dom樹，然後渲染成頁面呈現給使用者。

　　這種模式現在依然在某些web應用的開發中被使用。這種模式現在更多的被稱為傳統開發模式，或是前後端混合開發模式。其主要的一個特點是，頁面模板由後端吐出，甚至吐出的模板會帶有樣式和互動。前端只是將模板丟給瀏覽器渲染成dom樹生成頁面。有時候，前端也會注入一些js程式碼為頁面的動態互動提供支援。

　　這種開發模式，我自己是實際經歷過的。以前JavaEE、JavaWeb比較火的時候，常常會寫一個某某系統，例如學生管理系統、圖書管理系統之類的，在server端透過java來操作JDBC連結資料庫，拿到需要的數據，然後將數據與jsp組裝起來一起傳送給客戶端，客戶端再交給瀏覽器渲染。後來也經歷過php加smarty的開發模式。其實這兩種雖然使用的是不同的技術棧，但開發模式的本質是一樣的。

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

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

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

　　上面基本上就是前後端分離的演化歷史。

前後端分離開發模式下，server端從資料庫拿到元數據，經過處理後直接吐出數據，而不是範本。 client端拿資料之後，在客戶端端進行範本渲染產生頁面呈現給使用者。

　　相比傳統開發模式，此時服務端不再處理模板層的業務，而是直接只提供資料。職責更加單一。此時的服務端可能會根據不同業務需求或架構差異，也可能直接提供服務。這裡服務的含義往往指涉的是微服務。甚至在一些非絕對的前後端分離模式下，服務端還會提供模板片段。

　　顯而易見，此模式下，前端開發需要做更多的事，而且可能會隨著業務的成長前端邏輯和程式碼量會越來越龐大和複雜。這又推動了各種前端框架的湧現，例如Angular這種大而全的框架，例如React這種專註解決某一個層面業務的框架，例如Webpack這種彌補建構功能缺失的框架，等等。各種框架本身又會帶動其周邊社區的發展，使得整體前端開發圈呈現技術爆炸性的發展。

　　除了傳統Web開發之外，因為行動互聯網的快速發展，行動端開發、微信開發、h5開發等等範疇，也被前端開發者們照單全收。還有，由於NodeJS平台的崛起，前端開發可能已經​​不僅限於瀏覽器端的開發工作，借助NodeJS平台，以及Express、Koa等框架，前端開發者已經具備了涉足服務端開發的能力。

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

　　所以，可以探討的內容實在是非常的多，本文不會過度發散，只是探討Web開發相關的內容。以下將重心放在pc端的web開發模式的探討上，以前後端分離為出發點，闡述本人經歷過的兩種開發模式，以拋磚引玉。

　　中間層模式

　　前面有說過，因為NodeJS平台的活躍，特別是一些成熟的服務端開發框架的出現，例如express、koa等，讓前端開發者使用JavaScript進行服務端程式的開發成為可能，甚至還可以操作資料庫。這也給之前一直在瀏覽器端開發的前端開發者們開闢了新的工作場景，如果再掌握一些數據庫，http協議，網絡安全，web server等方面的知識，那麼我個人感覺前端開發者完全可以將自己的角色切換成一個後端開發，處理一些通用場景下的後端開發應該是沒有問題的。

　　顯而易見，這對傳統的前端開發者們提出了更高的要求，工作內容涉足的領域相比之前而言更加底層，會更加頻繁的去和真正的後台開發者進行溝通，甚至會參與一些約定和規範的製定，這時候又會要求我們能夠有一些後端思維，否則你跟別人在溝通事情的時候都不在頻道上，那怎麼可以呢?!

　　這部分內容的標題是中間層模式，那麼什麼是中間層模式呢?我個人的理解是，以前後端分離為出發點，借助NodeJS平台，在web後端與傳統前端(UI層)之間增加一層中間層，負責處理數據、模板、業務等內容。它是後端與UI層的橋樑。有的人喜歡稱這個中間層為膠水層。

　首先，這裡可能沒有明確意義上的後端，取而代之是REST Server、Micro Service等內容。他們的本質依然是對上層提供數據。這些內容都屬於backend的範疇。

　　backend的上層就是frontend。這裡所謂的frontend其實是一種廣泛的指代，它表示了一個回應使用者請求、互動等操作的集合。在這個集合中，最上層是用戶，然後是客戶端(瀏覽器)層，然後客戶端的的下面是NodeJS層。另外還會有一個nginx層。

　　第一種場景，當使用者發起一個頁面請求時，瀏覽端會先接受這個請求，然後丟給nginx來代理，nginx根據請求的類型將請求轉發給對應的NodeJS層服務。 NodeJS層內部會解析來自nginx層轉發的請求，執行對應的業務類，組裝數據，最終輸出一個html模板給客戶端(瀏覽器)，瀏覽器端拿到模板之後，注入客戶端的js和css代碼之後再渲染到成頁面，呈現給使用者。

　　第二種場景，用戶在頁面發起交互請求時，例如點擊按鈕發起請求，此時這個請求最終會丟給NodeJS層，NodeJS層收到請求之後進行處理，然後將響應返回給瀏覽器。

　　基本上，絕大部分來自客戶端(UI層)的請求和交互都會在NodeJS層進行處理，UI層與底層的REST服務或微服務是隔離的。當然也有特例，例如圖片驗證碼這種場景，會由瀏覽器直接要求底層REST服務或微服務。

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

　　這裡我嘗試給一個中間層模式的解決方案sword-plus。它的定位並不是大而全的一站式解決方案，而是為了更便利的開發NodeJS層的一系列工具集合以及常用功能的提煉。基於Koa程序，提供了日誌記錄、範本渲染、請求存取、路由解析、業務類別抽像等功能。其內部的各個功能組件存在一定程度上的偶合。所以使用sword-plus的前提是，引入NodeJS作為中間層;底層的框架選型為Koa;NodeJS層向上層提供組裝好資料的模板。

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

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

　　parse，解析路由

　　provider，生成業務類，並啟動對應路由的業務邏輯

　　Pugger主要用於組裝數據並渲染Jade/Pug模板。

　　這裡的模板屬於服務端模板，在渲染的過程中，可透過參數配置是否記錄渲染日誌。

　　主要方法render，用於組裝資料產生服務端模板。

　　渲染日誌將會記錄在渲染過程中的任何報錯資訊。

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

　　get，執行get請求

　　post，執行post請求

　　Logger是日誌組件，Logger將所有的日誌分為如下幾大類(category)，

〜、〜 info

　　request、response、render、action

　　其中第一行其實是bunyan自帶日誌等級的alias，第二行是根據不同業務場景抽像出來的。

　　request，NodeJS程式向REST伺服器發送rest API請求的日誌

　　response，REST伺服器傳回給NodeJS程式的rest api回應的日誌

　　render，服務端對服務端的建模客戶端(瀏覽器)是沒有關係的，它僅僅表示模板文件和資料的組裝和編譯過程

　　action，所有由用戶發起從而產生的交互日誌，包括頁面請求、表單提交、客戶端ajax請求等等

　　每一條日誌都是一個record抽象，每個record實例在category的維度下，還會有level的區分，常用的level有以下幾種info、warn和error。

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

　　inherits，在Router解析完畢之後，在Router.provider中透過此方法產生特定的業務類Clazz。

　　dispatch，在業務類別中對get和post請求類型進行自適配轉發。

　　inject，在server啟動時，可以根據需要注入外部拓展，一旦注入，則在所有生成的業務類中都可使用。

　　SwordError是SwordPlus的Error封裝。用於統一分配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

　完全分離模式

所謂的完全分離模式，即此模式下的前端開發和傳統意義上的後端開發完全隔離開，不會涉及中間層的開發。

前端和後端透過ajax請求來交互，後端返回給前端資料。客戶端的所有事情，包括頁面渲染、互動、樣式、路由等等都是由前端自己來管理。此時前端開發往往會引進一個較成熟的前端開源框架作為底層選型。這種開發模式有其獨特的適用場景，例如單頁應用程式(Single Page Application)、企業內部的某個管理系統等等。如果前端開發對底層選型的框架較為熟悉，往往開發速度非常快，基本上在實際開發中遇到的一些問題都可以在框架社群中找到解決方案。

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

　　我個人的看法是，根據場景和需求來進行實現方案和技術的選型，不要一味的追求新技術和潮流。目前前端圈子中流行的幾種主流框架，例如Angular，React，Vue等都會有其優勢和弱勢的地方。例如，Angular本身就是包羅萬象的框架，一旦熟悉起來開發速度非常快，但是其入門門檻低深入比較複雜，而且有一些場景是其先天不適合的。 React只專注於View層的處理，提供了一個非常好的想法告訴我們應該如何做View和Data層的互動和更新，但是其現有的資料狀態管理方案例如Redux，我個人感覺一直都不是太好用。 VueJS的作者吸收了市面上眾多框架的優勢，個人感覺它一直都在發展中，本人並沒有在生產環境中使用過，不作過多評價。

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

　　總結

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