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