基于前后端分離的模版探索
前言
在做前后端分離時,***個關(guān)注到的問題就是 渲染,也就是 View 這個層面的工作。
在傳統(tǒng)的開發(fā)模式中,瀏覽器端與服務(wù)器端是由不同的前后端兩個團隊開發(fā),但是模版卻又在這兩者中間的模糊地帶。因此模版上面總不可避免的越來越多復(fù)雜邏輯,最終難以維護。
而我們選擇了NodeJS,作為一個前后端的中間層。試圖藉由NodeJS,來疏理 View 層面的工作。
使得前后端分工更明確,讓專案更好維護,達成更好的用戶體驗。
本文
渲染這塊工作,對于前端開發(fā)者的日常工作來說,佔了非常大的比例,也是最容易與后端開發(fā)糾結(jié)不清的地方。
回首過去前端技術(shù)發(fā)展的這幾年, View 這個層面的工作,經(jīng)過了許多次的變革,像是:
- Form Submit 全頁刷新 => AJAX局部刷新
- 服務(wù)端續(xù)染 + MVC => 客戶端渲染 + MVC
- 傳統(tǒng)換頁跳轉(zhuǎn) => 單頁面應(yīng)用
可以觀察到在這幾年,大家都傾向?qū)?渲染 這件事,從服務(wù)器端端移向了瀏覽器端。
而服務(wù)器端則專注于 服務(wù)化 ,提供數(shù)據(jù)接口。
瀏覽器端渲染的好處
瀏覽器端渲染的好處,我們都很清楚,像是
- 擺脫業(yè)務(wù)邏輯與呈現(xiàn)邏輯在Java模版引擎中的耦合與混亂。
- 針對多終端應(yīng)用,更容易以接口化的形式。在瀏覽器端搭配不同的模版,呈現(xiàn)不同的應(yīng)用。
- 頁面呈現(xiàn)本來就不僅是html,在前端的渲染可以更輕易的以組件化形式 (html + js + css)提供功能,使得前端組件不需依賴于服務(wù)端產(chǎn)生的html結(jié)構(gòu)。
- 脫離對于后端開發(fā)、發(fā)佈流程的依賴。
- 方便聯(lián)調(diào)。
瀏覽器端渲染造成的壞處
但是在享受好處的同時,我們同樣的也面臨了 瀏覽器端渲染 所帶來的壞處,像是:
- 模版分離在不同的庫。有的模版放在服務(wù)端 (JAVA),而有的放在瀏覽器端 (JS)。前后端模版語言不相通。
- 需要等待所有模版與組件在瀏覽器端載入完成后才能開始渲染,無法即開即看。
- ***進入會有白屏等待渲染的時間,不利于用戶體驗
- 開發(fā)單頁面應(yīng)用時,前端Route與服務(wù)器端Route不匹配,處理起來很麻煩。
- 重要內(nèi)容都在前端組裝,不利于SEO
反思前后端的定義
其實回頭想想,在我們把渲染的工作從 服務(wù)端(Java) 抽出來到 瀏覽器端(JS) 的時候,我們的目的只是 明確的前后端職責(zé)劃分,并不是非瀏覽器渲染不可 。
只是因為在傳統(tǒng)的開發(fā)模式中,出了服務(wù)器就到了瀏覽器,所以前端的工作內(nèi)容只能被限制在瀏覽器端。
也因此很多人認定了 后端 = 服務(wù)端
前端 = 瀏覽器端
,就像下面這張圖。
而在淘寶UED目前進行的 中途島Midway 項目中,藉由在 JAVA – Browser中間搭建一個NodeJS中間層,試圖把這個前后端的分割線,重新針對 工作職責(zé) 去區(qū)分,而分針對硬體環(huán)境去區(qū)分(服務(wù)器 & 瀏覽器)。
因此我們有機會做到模版與路由的共享,也是一個前后端分工中最理想的狀態(tài)。
淘寶中途島 Midway
在中途島項目中,我們把前后端分界的那條線,從瀏覽器端移回到了服務(wù)器端。
藉由一個由前端 輕松掌控 且 與瀏覽器共通 的Nodejs層,可以更清晰的完成了前后端分離。
也可以讓前端開發(fā)針對不同的情況,自行決定 最適當(dāng)?shù)慕鉀Q方案 。而不是所有事情 都在瀏覽器端來處理 。
職責(zé)劃分
中途島并不是前端試圖搶后端飯碗的項目,目的只是把 模版 這個模糊地帶切割清楚,取得更明確的職責(zé)劃分。
- 后端 (JAVA),專注于
- 服務(wù)層
- 數(shù)據(jù)格式、數(shù)據(jù)穩(wěn)定
- 業(yè)務(wù)邏輯
- 前端,專注于
- UI層
- 控只邏輯、渲染邏輯
- 交互、用戶體驗
而不再拘泥于服務(wù)端或瀏覽器端的差異。
模版共享
在傳統(tǒng)的開發(fā)模式中,瀏覽器端與服務(wù)器端是由不同的前后端兩個團隊開發(fā),但是模版卻又在這兩者中間的模糊地帶。因此模版上面總不可避免的越來越多復(fù)雜邏輯,最終難以維護。
有了NodeJS,后端同學(xué)可以在JAVA層專注于業(yè)務(wù)邏輯與數(shù)據(jù)的開發(fā)。而前端同學(xué)則專注于控制邏輯與渲染的開發(fā)。并且自行選擇這些模版是要在 服務(wù)端 (NodeJS) 或是 瀏覽器端 做渲染。
用著一樣的模版語言 XTemplate ,一樣的渲染引擎 JavaScript
在 不同的渲染環(huán)境 (Server-side、PC Browser、Mobile Browser、Web View、etc.) 渲染出 一樣的結(jié)果 。
路由共享
也因為有了NodeJS這一層,可以更細致的控制路由。
假如需要在前端做瀏覽器端路由時,可以同時配置服務(wù)器端的路由,使其在 瀏覽器端換頁 或是 服務(wù)端換頁 ,都可以得到一致的渲染效果。
同時也處理了SEO的問題。
模版共享的實踐
通常我們在瀏覽器端渲染一份模版時,流程不外乎是
- 在瀏覽器端載入模版引擎 (xtmpleate, juicer, handlerbar, etc.)
- 在瀏覽器端載入模版檔案,方法可能有
- 使用
<script type="js/tpl"> ... </script>
印在頁面上 - 使用模塊載入工具,載入模版檔案 (KISSY, requireJS, etc.)
- 其他
- 使用
- 取得數(shù)據(jù),使用模版引擎產(chǎn)生html
- 將html插入到指定位置。
從以上的流程可以觀察到,要想要做到模版的跨端共享,重點其實在 一致的模塊選型 這件事。
市面上流行很多種模塊標(biāo)準(zhǔn),例如 KMD、AMD、CommonJS,只要能將NodeJS的模版檔案透過一致模塊規(guī)范輸出到NodeJS端,就可以做基本的模版共享了。
而后續(xù)的系列文章會針對Model的proxy與共享,做進一步的探討。
案例探討
因為有了中途島這中間層,針對過往的一些問題都有了更好的解答,例如說
案例一 復(fù)雜交互應(yīng)用 (如購物車、下單頁面)
- 狀況:全部的HTML都是在前端渲染完成,服務(wù)端僅提供接口。
- 問題:進入頁面時,會有短暫白屏。
- 解答:
- ***進入頁面,在NodeJS端進行 全頁渲染 ,并在背景下載相關(guān)的模版。
- 后續(xù)交互操作,在瀏覽器端完成 局部刷新
- 用的是 同一份模版 , 產(chǎn)生 一樣的結(jié)果
案例二 單頁面應(yīng)用
- 狀況:使用Client Side MVC框架,在瀏覽器換頁。
- 問題:渲染與換頁都在瀏覽器端完成,直接輸入網(wǎng)址進入或f5刷新時,無法直接呈現(xiàn)同樣的內(nèi)容。
- 解答:
- 在瀏覽器端與NodeJS端共享 同樣的Route 設(shè)定
- 瀏覽器端換頁時,在瀏覽器端進行Route變更與 頁面內(nèi)容渲染
- 直接輸入同樣的網(wǎng)址時,在NodeJS端進行 頁面框架 + 頁面內(nèi)容渲染
- 不管是瀏覽器端換頁,或直接輸入同樣的網(wǎng)址,看到的內(nèi)容都是 一樣的 。
- 除了增加體驗、減少邏輯複雜度外。更解決了 SEO 的問題
案例三 純?yōu)g覽型頁面
- 狀況:頁面僅提供資訊,較少或沒有交互
- 問題:html在服務(wù)端產(chǎn)生,css與js放在另外一個位置,彼此間有依賴。
- 解答:
- 透過NodeJS,統(tǒng)一管理html + css + js
- 日后若需要擴展成復(fù)雜應(yīng)用或是單頁面應(yīng)用,也可以輕易轉(zhuǎn)移。
案例四 跨終端頁面
- 狀況:同樣的應(yīng)用要在不同端點呈現(xiàn)不同的介面與交互
- 問題:html管理不易,常常會在服務(wù)端產(chǎn)生不一樣的html,瀏覽器端又要做不一樣的處理
- 解答:
- 跨終端的頁面是渲染的問題,統(tǒng)一由前端來處理。
- 透過NodeJS層與后端服務(wù)化,可以針對這類型復(fù)雜應(yīng)用,設(shè)計***的解決方案。
總結(jié)
過去的AJAX、Client-side MVC、SPA、Two-way Data Binding 等技術(shù)的出現(xiàn),都是試圖要解決當(dāng)時的前端開發(fā)遇到的瓶頸。
而NodeJS中間層的出現(xiàn),也是在試圖解決現(xiàn)今前端被侷限在瀏覽器端的一個限制。
這邊文章專注于前后端模版共享,也希望能拋磚引玉,與大家一起討論如何在NodeJS中間層這個架構(gòu)下,我們可以怎樣的改善我們的工作流程,怎樣的跟 后端配合,來把 前端 這個工作做得更好。