基本介紹

首先從一個(gè)重要的概念“模板”說(shuō)起。 廣義上來(lái)說(shuō)，web中的模板就是填充數(shù)據(jù)后可以生成文件的頁(yè)面。 嚴(yán)格意義上來(lái)說(shuō)，應(yīng)該是模板引擎利用特定格式的文件和所提供的數(shù)據(jù)編譯生成頁(yè)面。模板大致分為前端模板（如ejs）和后端模板（如freemarker）分別在瀏覽器端和服務(wù)器端編譯。

由于當(dāng)場(chǎng)有一部分同學(xué)對(duì)node.js并不是很了解，這里補(bǔ)充一下node.js的相關(guān)知識(shí)。官網(wǎng)上的給他的定義事件驅(qū)動(dòng)、異步什么的就不說(shuō)了。這里借用樸靈書(shū)上的一張圖來(lái)解釋一下node.js這個(gè)玩意的結(jié)構(gòu)。如果懂java的同學(xué)可以將其理解為js版本的jvm。 瀏覽器一般包括渲染器和js腳本引擎，以chrome瀏覽器為例，用的webkit內(nèi)核的渲染器，V8的腳本引擎，而node.js用到了v8引擎?？偠灾褪且粋€(gè)js的運(yùn)行環(huán)境，就好比瀏覽器的F12調(diào)試工具，只不過(guò)node.js沒(méi)有DOM和BOM。

這張圖描述的是node.js周邊的一些信息，比如npm這個(gè)出色的包管理器和cnode社區(qū)以及github，都在一定程度上促進(jìn)了node.js的繁榮，提供了技術(shù)保障。

大公司通常都是技術(shù)的風(fēng)向標(biāo)，例如google的angular、facebook的react現(xiàn)在都很火。這里只列了3個(gè)大公司當(dāng)作例子。淘寶的中途島架構(gòu)就不用說(shuō)了，國(guó)內(nèi)node.js的先行者樸靈就來(lái)自淘寶。去哪兒也出了個(gè)應(yīng)該叫做“QTX”的技術(shù)框架。360月影帶領(lǐng)的75團(tuán)隊(duì)出了個(gè)基于ES6/ES7的web服務(wù)器框架——thinkjs，當(dāng)時(shí)我們技術(shù)總監(jiān)很看好，但是由于鄙人沒(méi)有時(shí)間學(xué)習(xí)ES6再加上插件不夠豐富，所以還是選用了較為成熟的Express。

言歸正傳，這個(gè)表格列出了我所接觸過(guò)的3種前后端分離的開(kāi)發(fā)方式。 第一種是最常見(jiàn)的使用java之類(lèi)的后端語(yǔ)言模板，SEO友好，緩存利用率和減輕瀏覽器渲染負(fù)擔(dān)方面都比較好，最大的問(wèn)題就是模板文件的耦合度太高，出了問(wèn)題誰(shuí)都不想來(lái)解決，前端人員看不到數(shù)據(jù)，后端人員不懂頁(yè)面，模板文件就像是一個(gè)燙手的山芋。 第二種是目前我們項(xiàng)目移動(dòng)端的實(shí)現(xiàn)方案，利用angular這種框架（angular的指令可以看成是前端模板）和nginx這種反向代理服務(wù)器，讓前后端徹底解耦，只通過(guò)ajax交互數(shù)據(jù)。這種方案和前一種的優(yōu)缺點(diǎn)剛好相反。前端模板的性能始終是個(gè)問(wèn)題，尤其是在移動(dòng)端，更尤其是在低端的移動(dòng)設(shè)備上。 最后一種是新項(xiàng)目使用的用node.js做前端服務(wù)器，將前端的職責(zé)從瀏覽器劃分到了模板這一層，解決了以上所有的問(wèn)題，不過(guò)確實(shí)也有新的問(wèn)題，這種問(wèn)題稍后再分析。

當(dāng)然全棧開(kāi)發(fā)在小型項(xiàng)目中也是非常適合的。對(duì)于傳統(tǒng)的jsp/php開(kāi)發(fā)來(lái)說(shuō)，全棧開(kāi)發(fā)的溝通成本更低，開(kāi)發(fā)人員能更容易理解整個(gè)功能模塊，從而更好的還原產(chǎn)品的設(shè)計(jì)。尤其現(xiàn)在出現(xiàn)的以js語(yǔ)言為基礎(chǔ)的全棧開(kāi)發(fā)：meteor和MEAN技術(shù)，更是使得前后端開(kāi)發(fā)用一種語(yǔ)言直接搞定，再配上Mongodb，數(shù)據(jù)從瀏覽器到數(shù)據(jù)庫(kù)都無(wú)需轉(zhuǎn)義直接使用，還不用寫(xiě)sql，開(kāi)發(fā)成本又大大降低。

這次搭建node.js服務(wù)器用到的一些插件。 鼎鼎大名的express不用多介紹了，輕量級(jí)web服務(wù)器框架。 用handlebars模板引擎也屬巧合，因?yàn)閑xpress4默認(rèn)就是它，handlebars不愧為“弱邏輯”的模板引擎，主張的是減少模板邏輯，盡量只用變量和分頁(yè)，基于它的設(shè)計(jì)理念，我只擴(kuò)充了兩個(gè)helper。因?yàn)樗臏y(cè)試代碼用的是supertest，supertest是基于superagent，所以用了superagent來(lái)轉(zhuǎn)發(fā)和發(fā)起請(qǐng)求。superagent還是太弱了，長(zhǎng)連接都無(wú)法建立，還是推薦request插件。 restfuleAPI就沒(méi)什么好介紹了，前端服務(wù)器與瀏覽器，前端服務(wù)器與后端服務(wù)器都是用的這一套規(guī)范，基本上就是url指向資源，增刪改查又具體的請(qǐng)求方法表示，狀態(tài)碼表示結(jié)果等~ gulp打包工具，webpack研究了很久，發(fā)現(xiàn)每增加一個(gè)頁(yè)面都要修改配置文件，這個(gè)太頭疼，遂放棄。

開(kāi)發(fā)流程

如果這次分享主要是講怎樣將node.js做為前端服務(wù)器來(lái)實(shí)現(xiàn)前后端分離的話那也沒(méi)什么好講的，看看淘寶UED的文章就好了。前后端分離其實(shí)最大的問(wèn)題是帶來(lái)溝通成本的上升，具體來(lái)說(shuō)就是接口的定義和調(diào)試。在上圖的傳統(tǒng)開(kāi)發(fā)流程中，接口的定義會(huì)放在接口服務(wù)器中，然后前后端各自根據(jù)接口文檔造假數(shù)據(jù)進(jìn)行本地調(diào)試，之后進(jìn)行聯(lián)調(diào)。這個(gè)環(huán)節(jié)就是前后端開(kāi)始打架的時(shí)候了，這個(gè)參數(shù)不對(duì)，那個(gè)返回值不對(duì)，總之很浪費(fèi)時(shí)間。接下來(lái)看這個(gè)問(wèn)題在我們項(xiàng)目中是怎么解決的~

前后端因?yàn)榻涌诖蚣艿膯?wèn)題一直存在，作為保守主義的我相信迭代開(kāi)發(fā)，所以第一步做的只是增加了一個(gè)mock服務(wù)器。這個(gè)服務(wù)器的神奇之處就是根據(jù)接口文檔自動(dòng)生成假數(shù)據(jù)，實(shí)現(xiàn)了接口即API，前端同學(xué)再也不用把數(shù)據(jù)寫(xiě)死進(jìn)行測(cè)試了。沒(méi)辦法，誰(shuí)叫我是前端開(kāi)發(fā)，首先想到自己人，嘿嘿~當(dāng)然這個(gè)只在一定程度上有利于前端開(kāi)發(fā)，后端的接口和文檔不一致聯(lián)調(diào)時(shí)也會(huì)出現(xiàn)問(wèn)題。怎么辦？

偶然在破浪大神的博客上看到老馬的一篇專(zhuān)門(mén)講前后端分離的文章，其中一個(gè)重要的概念就是契約測(cè)試也叫雙邊測(cè)試吧。核心概念就是為了解決遠(yuǎn)程聯(lián)調(diào)的問(wèn)題。對(duì)前后端的參數(shù)都進(jìn)行校驗(yàn)，要求大家按照接口文檔進(jìn)行開(kāi)發(fā)。受其啟發(fā)，加入json-schema規(guī)則，實(shí)現(xiàn)了對(duì)http請(qǐng)求的參數(shù)校驗(yàn)，誰(shuí)不按規(guī)矩來(lái)誰(shuí)改。

這個(gè)redmine是我們最早的接口文檔管理器，除了記錄和查看功能再無(wú)其他作用。

swagger號(hào)稱(chēng)世界最流行的接口文檔服務(wù)器，界面美觀，插件也還比較多，可以針對(duì)后端語(yǔ)言直接生成測(cè)試代碼。不過(guò)部署的時(shí)候始終沒(méi)玩懂，而且yaml格式不如json習(xí)慣，放棄了它。

這就是現(xiàn)在我們項(xiàng)目上用的文檔服務(wù)器和mock服務(wù)器，基于MEAN技術(shù)實(shí)現(xiàn)的服務(wù)器，基本功能：

利用mockjs插件，可以動(dòng)態(tài)生成隨機(jī)數(shù)據(jù)基于json-schema對(duì)接口參數(shù)實(shí)行校驗(yàn)和接口測(cè)試，并保存測(cè)試狀態(tài)和接口響應(yīng)時(shí)間。簡(jiǎn)單的json編輯器帶有登陸校驗(yàn)功能，可登陸后進(jìn)行接口調(diào)試mock服務(wù)器按照api服務(wù)器來(lái)響應(yīng)請(qǐng)求，接口更新時(shí)自動(dòng)更新

一些問(wèn)題

node.js是前端工程師的翅膀，而插上翅膀是變成天使還是變成惡魔？這個(gè)要看能不能解決的使用它時(shí)帶來(lái)的問(wèn)題了。

首先前端的工作量毫無(wú)疑問(wèn)地會(huì)增加，但溝通成本會(huì)降低。node.js單線程的服務(wù)器穩(wěn)定性確實(shí)不夠好，不過(guò)代碼的健壯性和完善的日志可以有效的規(guī)避。回調(diào)。這個(gè)問(wèn)題解決方法就太多了，node.js的q/async模塊以及ES6/ES7。node.js調(diào)試。雖然我一直排斥IDE，但不得不承認(rèn)webstorm在調(diào)試上確實(shí)很方便。我用的node-inspector也還湊合，界面類(lèi)似chrome開(kāi)發(fā)者工具，看上去挺熟悉的。

如果對(duì)于后端程序員，更加應(yīng)該擁簇node.js了。接口整合的工作交給了前端服務(wù)器進(jìn)行處理，同時(shí)和前端耦合度大大降低，工作量和工作效率都減少了。

心得體會(huì)有兩點(diǎn)

node.js的使用雖然有一定的學(xué)習(xí)成本，但對(duì)于前端開(kāi)發(fā)人員還是很友好的。而且前端使用node.js的話，無(wú)論是技術(shù)含量還是工作量都會(huì)有所提升，從而提升了崗位的重要性。當(dāng)前端開(kāi)發(fā)人員能創(chuàng)造更多價(jià)值的時(shí)候才有資格要求更高的薪水~工作中建議少提建議多給可行性方案，同時(shí)進(jìn)行技術(shù)預(yù)研而不是寫(xiě)個(gè)簡(jiǎn)單的helloworld。

總結(jié)

可能有人說(shuō)你介紹的這一套東西這么復(fù)雜，用起來(lái)太麻煩了，還不如面對(duì)面溝通。 對(duì)于這樣的質(zhì)疑我只能用騰訊高級(jí)UI工程師余果在《web全棧工程師的自我修養(yǎng)》中講到的一個(gè)例子。有一次他電面一家小公司的前端負(fù)責(zé)人問(wèn)他怎么管理代碼時(shí)，對(duì)方說(shuō)直接用ftp上傳，同時(shí)抱怨手下人老是更新錯(cuò)代碼，又問(wèn)他為什么不用svn或git，他說(shuō)還不如手動(dòng)更新方便。 這個(gè)故事的道理就是我面對(duì)質(zhì)疑的回答~

ppt下載地址

最新評(píng)論