前端靜態(tài)化

前端有且僅有靜態(tài)內容,再明確些,只有HTML/CSS/JS. 其內容來自于完全靜態(tài)的資源而不需要任何后臺技術進行動態(tài)化組裝.前端內容的運行環(huán)境和引擎完全基于瀏覽器本身.

后端數(shù)據(jù)化

后端可以用任何語言,技術和平臺實現(xiàn),但它們必須遵循一個原則:只提供數(shù)據(jù),不提供任何和界面表現(xiàn)有關的內容.換言之,他們提供的數(shù)據(jù)可以用于任何其他客戶端(如本地化程序,移動端程序).

平臺無關化

前端3大技術本身就是平臺無關的,而后臺連接部分的本質是實現(xiàn)合適的RESTful接口和交互Json數(shù)據(jù),就這2者而言,任何技術和平臺都可以實現(xiàn).

構架分離化

前端架構完全基于HTML/CSS的發(fā)展和JS框架的演變,與我們耳熟能詳?shù)暮笈_語言(如C#, Java, NodeJs等)完全無關. 由于前臺是純靜態(tài)內容,大型構架方面可以考慮向CDN方向發(fā)展.

后端構架幾乎可以基于任何語言和平臺的任何解決方案,大型構架方面, RESTful Api可以考慮負載均衡;而數(shù)據(jù),業(yè)務實現(xiàn)等可以考慮數(shù)據(jù)庫優(yōu)化和分布式,這些領域園內大牛如云,就不再班門弄斧了.

但總而言之,前后端的分離也實現(xiàn)了前后端構架的分離.

分離模式的優(yōu)勢 
1、前后端流量大幅減少

我們知道,前后端流量的大頭是HTML/JS/IMG資源,而數(shù)據(jù)僅僅是小頭,資源占到100K以上的頁面不算大,但數(shù)據(jù)充其量10K左右,比如一個1萬條記錄的數(shù)據(jù)經過壓縮也僅僅在100K左右,而一個稍大的JS庫或圖片就不止這些.

流量的減少在于”前端靜態(tài)化”這個規(guī)則,在第一次獲取以后靜態(tài)資源會被瀏覽器緩存,即使瀏覽器繼續(xù)輪詢,服務端也會返回一個非常小Not Modified響應,流量幾乎可以忽略不計.

舉例說明,在一個頁面為100K,數(shù)據(jù)為10K的頁面中,100次請求的流量是100K+10X100 = 1.1M. 顯而易見,其流量是大幅低于每次獲取完整HTML的情況的.

2、表現(xiàn)性能的提高

也有人質疑這種模式的頁面性能問題,其實情況沒有那么悲觀: 第一次獲取的確會有些許損失,但我認為,損失微乎其微,一個HTML頁面的加載,同時加載10多個幾十K的JS, Image的情況非常常見,再多1-2個10K的Json也并非沉重負擔.

但后續(xù)使用這個頁面,性能優(yōu)勢就完全體現(xiàn)了,頁面的絕大部分內容都是本地緩存直接加載,遠程獲取的僅僅是1-2個10K的內容,其加載時間百毫秒內,這和本地頁面幾無區(qū)別,其前端加載和響應速度得到非常大的提高是顯而易見的.

3、前后端平臺無關和技術無關

前端是純HTML技術,前端人員只需要記事本就可以開發(fā)并非一句”戲言”,而后端能夠實現(xiàn)RESTful的框架和平臺比比皆是, 完全可以選擇更適合團隊,人員和公司的技術路線而不在糾結于平臺和技術的選擇.

4、安全性方面的集中優(yōu)化

前端靜態(tài)化以后,前端頁面攻擊幾無可能,一些注入式攻擊在分離模式下被很好的規(guī)避; 而后端安全問題集中化了,僅僅只處理一個RESEful接口的安全考慮,安全架設和集中優(yōu)化變得更明確和便利.

5、開發(fā)的分離和構架的分離

也許很多團隊還是1個開發(fā)人員全包前后端的模式,但我也提到了,前端的要求越來越高,前后端人員的需求分化日益明顯,一旦系統(tǒng)上級別上檔次,其分離的需求必將出現(xiàn).

前后端人員的完全分離可以使得他們在各自領域進一步求深求專,成為更加專業(yè)的高手;另外,前后端的構架也可以分開考慮和架設,前端構架就能集中考慮性能和優(yōu)化,而業(yè)務,安全和存儲等問題就能集中到后端考慮.

可以說受益匪淺,而針對他們提出一些的問題,也嘗試在自己的構想下進行尋求解決方案:

頁面邏輯和呈現(xiàn)效果: 還是剛剛的一句話,JS已經無所不能,依托于目前的各種JS函數(shù)庫和框架,在獲取到合理的數(shù)據(jù)以后,幾乎沒有做不出來的邏輯和效果. 我本身偏向于前端實現(xiàn),對這點有疑問的朋友我們可以深入交流. 至于有些園友提出的數(shù)據(jù)校驗,頁面白屏,路由控制,代碼復用等等問題,前端技術已經完全可以解決.

6、服務器性能和優(yōu)化: 由于前端內容是完全的靜態(tài)內容,在初次獲取以后的大部分時間內,瀏覽器使用的就是本地緩存,也就是說,服務器的壓力主要來自于承載數(shù)據(jù)的Restful Api調用,壓力的大幅降低不言而喻.加上對交互數(shù)據(jù)的合理設計,可以說對客戶端-服務端的交互量控制已經接近極限.

7、安全性: 由于前端靜態(tài)內容僅僅只能獲取,而后端只能接受Json,應該說,屏蔽了大量可能發(fā)生的注入型問題,而一些其他問題,比如非法對象,數(shù)據(jù)加密,DDOS等問題,這些本身就是后端人員無法回避的責任,在任何模式下都必須考慮.

跨平臺,跨技術: 正如剛剛所所說, 前端技術本身無平臺限制,而后端幾乎任何平臺都能實現(xiàn).

實現(xiàn)

前后端人員雙方約定好接口的數(shù)據(jù)格式，比如：前端需要調用一個用戶信息的接口，數(shù)據(jù)格式為{name:”,gender:”}，那么，后端人員只需要告訴他一個接口url（如： http://192.168.1.2:8080/pro/userInfo），并且將這個接口返回前端想要的數(shù)據(jù)即可，至于后端人員怎么實現(xiàn)這個接口，前端人員并不關心！ 
前端頁面用ajax解析url，獲取數(shù)據(jù)進行頁面端的處理，然后再按照上述地址返回給后端，就想APP和后臺接口對接是一個道理。 
至于前端人員要用這個接口來做什么，后端人員同樣不需要關心！雙方都只專注于自己需要實現(xiàn)的業(yè)務邏輯。

順便說一下AMS7.0預計年內發(fā)布，AMS主程序全部用C++開發(fā)，AMS通過REST API提供所有接口，并提供Web容器，AMS7將 采用JS + CSS +HTML提供一套全新的基于前后端分離技術的Web頁面，基于復雜直播、點播、轉碼、設備管理，用戶管理，系統(tǒng)功能等功能皆可完美呈現(xiàn)。