前言

在做前后端分離時(shí)，第一個(gè)關(guān)注到的問(wèn)題就是 渲染，也就是 View 這個(gè)層面的工作。

在傳統(tǒng)的開發(fā)模式中，瀏覽器端與服務(wù)器端是由不同的前后端兩個(gè)團(tuán)隊(duì)開發(fā)，但是模版卻又在這兩者中間的模糊地帶。因此模版上面總不可避免的越來(lái)越多復(fù)雜邏輯，最終難以維護(hù)。

而我們選擇了NodeJS，作為一個(gè)前后端的中間層。試圖藉由NodeJS，來(lái)疏理 View 層面的工作。

使得前后端分工更明確，讓專案更好維護(hù)，達(dá)成更好的用戶體驗(yàn)。

本文

渲染這塊工作，對(duì)于前端開發(fā)者的日常工作來(lái)說(shuō)，佔(zhàn)了非常大的比例，也是最容易與后端開發(fā)糾結(jié)不清的地方。

回首過(guò)去前端技術(shù)發(fā)展的這幾年， View 這個(gè)層面的工作，經(jīng)過(guò)了許多次的變革，像是：

Form Submit 全頁(yè)刷新 => AJAX局部刷新
服務(wù)端續(xù)染 + MVC => 客戶端渲染 + MVC
傳統(tǒng)換頁(yè)跳轉(zhuǎn) => 單頁(yè)面應(yīng)用
可以觀察到在這幾年，大家都傾向?qū)?渲染 這件事，從服務(wù)器端端移向了瀏覽器端。

而服務(wù)器端則專注于 服務(wù)化 ，提供數(shù)據(jù)接口。

瀏覽器端渲染的好處

瀏覽器端渲染的好處，我們都很清楚，像是

1.擺脫業(yè)務(wù)邏輯與呈現(xiàn)邏輯在Java模版引擎中的耦合與混亂。
2.針對(duì)多終端應(yīng)用，更容易以接口化的形式。在瀏覽器端搭配不同的模版，呈現(xiàn)不同的應(yīng)用。
3.頁(yè)面呈現(xiàn)本來(lái)就不僅是html，在前端的渲染可以更輕易的以組件化形式 (html + js + css)提供功能，使得前端組件不需依賴于服務(wù)端產(chǎn)生的html結(jié)構(gòu)。
4.脫離對(duì)于后端開發(fā)、發(fā)佈流程的依賴。
5.方便聯(lián)調(diào)。

瀏覽器端渲染造成的壞處

但是在享受好處的同時(shí)，我們同樣的也面臨了 瀏覽器端渲染 所帶來(lái)的壞處，像是：

1.模版分離在不同的庫(kù)。有的模版放在服務(wù)端 (JAVA)，而有的放在瀏覽器端 (JS)。前后端模版語(yǔ)言不相通。
2.需要等待所有模版與組件在瀏覽器端載入完成后才能開始渲染，無(wú)法即開即看。
3.首次進(jìn)入會(huì)有白屏等待渲染的時(shí)間，不利于用戶體驗(yàn)
4.開發(fā)單頁(yè)面應(yīng)用時(shí)，前端Route與服務(wù)器端Route不匹配，處理起來(lái)很麻煩。
5.重要內(nèi)容都在前端組裝，不利于SEO

反思前后端的定義

其實(shí)回頭想想，在我們把渲染的工作從 服務(wù)端(Java) 抽出來(lái)到 瀏覽器端(JS) 的時(shí)候，我們的目的只是 明確的前后端職責(zé)劃分，并不是非瀏覽器渲染不可 。

只是因?yàn)樵趥鹘y(tǒng)的開發(fā)模式中，出了服務(wù)器就到了瀏覽器，所以前端的工作內(nèi)容只能被限制在瀏覽器端。

也因此很多人認(rèn)定了 后端 = 服務(wù)端 前端 = 瀏覽器端 ，就像下面這張圖。

而在淘寶UED目前進(jìn)行的 中途島Midway 項(xiàng)目中，藉由在 JAVA – Browser中間搭建一個(gè)NodeJS中間層，試圖把這個(gè)前后端的分割線，重新針對(duì) 工作職責(zé) 去區(qū)分，而非針對(duì)硬體環(huán)境去區(qū)分（服務(wù)器 & 瀏覽器）。

因此我們有機(jī)會(huì)做到模版與路由的共享，也是一個(gè)前后端分工中最理想的狀態(tài)。

淘寶中途島 Midway

在中途島項(xiàng)目中，我們把前后端分界的那條線，從瀏覽器端移回到了服務(wù)器端。

藉由一個(gè)由前端 輕松掌控 且 與瀏覽器共通 的Nodejs層，可以更清晰的完成了前后端分離。

也可以讓前端開發(fā)針對(duì)不同的情況，自行決定 最適當(dāng)?shù)慕鉀Q方案 。而不是所有事情 都在瀏覽器端來(lái)處理 。

職責(zé)劃分

中途島并不是前端試圖搶后端飯碗的項(xiàng)目，目的只是把 模版 這個(gè)模糊地帶切割清楚，取得更明確的職責(zé)劃分。

后端 (JAVA)，專注于
1.服務(wù)層
2.數(shù)據(jù)格式、數(shù)據(jù)穩(wěn)定
3.業(yè)務(wù)邏輯
 
前端，專注于
1.UI層
2.控制邏輯、渲染邏輯
3.交互、用戶體驗(yàn)
 
而不再拘泥于服務(wù)端或?yàn)g覽器端的差異。

模版共享

在傳統(tǒng)的開發(fā)模式中，瀏覽器端與服務(wù)器端是由不同的前后端兩個(gè)團(tuán)隊(duì)開發(fā)，但是模版卻又在這兩者中間的模糊地帶。因此模版上面總不可避免的越來(lái)越多復(fù)雜邏輯，最終難以維護(hù)。

有了NodeJS，后端同學(xué)可以在JAVA層專注于業(yè)務(wù)邏輯與數(shù)據(jù)的開發(fā)。而前端同學(xué)則專注于控制邏輯與渲染的開發(fā)。并且自行選擇這些模版是要在 服務(wù)端 (NodeJS) 或是 瀏覽器端 做渲染。

用著一樣的模版語(yǔ)言 XTemplate ，一樣的渲染引擎 JavaScript

在 不同的渲染環(huán)境?。⊿erver-side、PC Browser、Mobile Browser、Web View、etc.） 渲染出 一樣的結(jié)果 。

路由共享

也因?yàn)橛辛薔odeJS這一層，可以更細(xì)致的控制路由。

假如需要在前端做瀏覽器端路由時(shí)，可以同時(shí)配置服務(wù)器端的路由，使其在 瀏覽器端換頁(yè) 或是 服務(wù)端換頁(yè) ，都可以得到一致的渲染效果。

同時(shí)也處理了SEO的問(wèn)題。

模版共享的實(shí)踐

通常我們?cè)跒g覽器端渲染一份模版時(shí)，流程不外乎是

在瀏覽器端載入模版引擎 （xtmpleate, juicer, handlerbar, etc.）
在瀏覽器端載入模版檔案，方法可能有
使用 <script type="js/tpl"> ... </script> 印在頁(yè)面上
使用模塊載入工具，載入模版檔案 （KISSY, requireJS, etc.）
其他
取得數(shù)據(jù)，使用模版引擎產(chǎn)生html
將html插入到指定位置。
從以上的流程可以觀察到，要想要做到模版的跨端共享，重點(diǎn)其實(shí)在 一致的模塊選型 這件事。

市面上流行很多種模塊標(biāo)準(zhǔn)，例如 KMD、AMD、CommonJS，只要能將NodeJS的模版檔案透過(guò)一致模塊規(guī)范輸出到NodeJS端，就可以做基本的模版共享了。

而后續(xù)的系列文章會(huì)針對(duì)Model的proxy與共享，做進(jìn)一步的探討。

案例探討

因?yàn)橛辛酥型緧u這中間層，針對(duì)過(guò)往的一些問(wèn)題都有了更好的解答，例如說(shuō)

案例一 復(fù)雜交互應(yīng)用 （如購(gòu)物車、下單頁(yè)面）

狀況：全部的HTML都是在前端渲染完成，服務(wù)端僅提供接口。
問(wèn)題：進(jìn)入頁(yè)面時(shí)，會(huì)有短暫白屏。
解答：
首次進(jìn)入頁(yè)面，在NodeJS端進(jìn)行 全頁(yè)渲染 ，并在背景下載相關(guān)的模版。
后續(xù)交互操作，在瀏覽器端完成 局部刷新
用的是 同一份模版 ， 產(chǎn)生 一樣的結(jié)果

案例二 單頁(yè)面應(yīng)用

狀況：使用Client Side MVC框架，在瀏覽器換頁(yè)。
問(wèn)題：渲染與換頁(yè)都在瀏覽器端完成，直接輸入網(wǎng)址進(jìn)入或f5刷新時(shí)，無(wú)法直接呈現(xiàn)同樣的內(nèi)容。
解答：
在瀏覽器端與NodeJS端共享 同樣的Route 設(shè)定
瀏覽器端換頁(yè)時(shí)，在瀏覽器端進(jìn)行Route變更與 頁(yè)面內(nèi)容渲染
直接輸入同樣的網(wǎng)址時(shí)，在NodeJS端進(jìn)行 頁(yè)面框架 + 頁(yè)面內(nèi)容渲染
不管是瀏覽器端換頁(yè)，或直接輸入同樣的網(wǎng)址，看到的內(nèi)容都是 一樣的 。
除了增加體驗(yàn)、減少邏輯複雜度外。更解決了 SEO 的問(wèn)題

案例三 純?yōu)g覽型頁(yè)面

狀況：頁(yè)面僅提供資訊，較少或沒(méi)有交互
問(wèn)題：html在服務(wù)端產(chǎn)生，css與js放在另外一個(gè)位置，彼此間有依賴。
解答：
透過(guò)NodeJS，統(tǒng)一管理html + css + js
日后若需要擴(kuò)展成復(fù)雜應(yīng)用或是單頁(yè)面應(yīng)用，也可以輕易轉(zhuǎn)移。

案例四 跨終端頁(yè)面

狀況：同樣的應(yīng)用要在不同端點(diǎn)呈現(xiàn)不同的介面與交互
問(wèn)題：html管理不易，常常會(huì)在服務(wù)端產(chǎn)生不一樣的html，瀏覽器端又要做不一樣的處理
解答：
跨終端的頁(yè)面是渲染的問(wèn)題，統(tǒng)一由前端來(lái)處理。
透過(guò)NodeJS層與后端服務(wù)化，可以針對(duì)這類型復(fù)雜應(yīng)用，設(shè)計(jì)最佳的解決方案。

總結(jié)

過(guò)去的AJAX、Client-side MVC、SPA、Two-way Data Binding 等技術(shù)的出現(xiàn)，都是試圖要解決當(dāng)時(shí)的前端開發(fā)遇到的瓶頸。

而NodeJS中間層的出現(xiàn)，也是在試圖解決現(xiàn)今前端被侷限在瀏覽器端的一個(gè)限制。

這邊文章專注于前后端模版共享，也希望能拋磚引玉，與大家一起討論如何在NodeJS中間層這個(gè)架構(gòu)下，我們可以怎樣的改善我們的工作流程，怎樣的跟 后端配合，來(lái)把 前端 這個(gè)工作做得更好。

最新評(píng)論