|
基本介紹
首先從一個重要的概念“模板”說起,。 廣義上來說,，web中的模板就是填充數(shù)據后可以生成文件的頁面。 嚴格意義上來說,，應該是模板引擎利用特定格式的文件和所提供的數(shù)據編譯生成頁面,。模板大致分為前端模板（如ejs）和后端模板（如freemarker）分別在瀏覽器端和服務器端編譯。
由于當場有一部分同學對node.js并不是很了解,，這里補充一下node.js的相關知識,。官網上的給他的定義事件驅動、異步什么的就不說了。這里借用樸靈書上的一張圖來解釋一下node.js這個玩意的結構,。如果懂java的同學可以將其理解為js版本的jvm,。 瀏覽器一般包括渲染器和js腳本引擎，以chrome瀏覽器為例,，用的webkit內核的渲染器,，V8的腳本引擎，而node.js用到了v8引擎,?？偠灾褪且粋€js的運行環(huán)境，就好比瀏覽器的F12調試工具,，只不過node.js沒有DOM和BOM,。
這張圖描述的是node.js周邊的一些信息，比如npm這個出色的包管理器和cnode社區(qū)以及github,，都在一定程度上促進了node.js的繁榮,，提供了技術保障。
大公司通常都是技術的風向標,，例如google的angular,、facebook的react現(xiàn)在都很火。這里只列了3個大公司當作例子,。淘寶的中途島架構就不用說了,，國內node.js的先行者樸靈就來自淘寶。去哪兒也出了個應該叫做“QTX”的技術框架,。360月影帶領的75團隊出了個基于ES6/ES7的web服務器框架——thinkjs,，當時我們技術總監(jiān)很看好，但是由于鄙人沒有時間學習ES6再加上插件不夠豐富,，所以還是選用了較為成熟的Express,。
言歸正傳,，這個表格列出了我所接觸過的3種前后端分離的開發(fā)方式,。 第一種是最常見的使用java之類的后端語言模板，SEO友好,，緩存利用率和減輕瀏覽器渲染負擔方面都比較好,，最大的問題就是模板文件的耦合度太高，出了問題誰都不想來解決,，前端人員看不到數(shù)據,，后端人員不懂頁面，模板文件就像是一個燙手的山芋,。 第二種是目前我們項目移動端的實現(xiàn)方案,，利用angular這種框架（angular的指令可以看成是前端模板）和nginx這種反向代理服務器，讓前后端徹底解耦，只通過ajax交互數(shù)據,。這種方案和前一種的優(yōu)缺點剛好相反,。前端模板的性能始終是個問題，尤其是在移動端,，更尤其是在低端的移動設備上,。 最后一種是新項目使用的用node.js做前端服務器，將前端的職責從瀏覽器劃分到了模板這一層,，解決了以上所有的問題,，不過確實也有新的問題，這種問題稍后再分析,。
當然全棧開發(fā)在小型項目中也是非常適合的,。對于傳統(tǒng)的jsp/php開發(fā)來說，全棧開發(fā)的溝通成本更低,，開發(fā)人員能更容易理解整個功能模塊,，從而更好的還原產品的設計。尤其現(xiàn)在出現(xiàn)的以js語言為基礎的全棧開發(fā)：meteor和MEAN技術,，更是使得前后端開發(fā)用一種語言直接搞定,，再配上Mongodb，數(shù)據從瀏覽器到數(shù)據庫都無需轉義直接使用,，還不用寫sql,，開發(fā)成本又大大降低。
這次搭建node.js服務器用到的一些插件,。 鼎鼎大名的express不用多介紹了,，輕量級web服務器框架。 用handlebars模板引擎也屬巧合,，因為express4默認就是它,，handlebars不愧為“弱邏輯”的模板引擎，主張的是減少模板邏輯,，盡量只用變量和分頁,，基于它的設計理念，我只擴充了兩個helper,。具體文章：https://yalishizhude./2016/01/22/handlebars/superagent的使用還是因為express4,，因為它的測試代碼用的是supertest，supertest是基于superagent,，所以用了superagent來轉發(fā)和發(fā)起請求,。superagent還是太弱了，長連接都無法建立,，還是推薦request插件,。 restfuleAPI就沒什么好介紹了，前端服務器與瀏覽器，前端服務器與后端服務器都是用的這一套規(guī)范,，基本上就是url指向資源,，增刪改查又具體的請求方法表示，狀態(tài)碼表示結果等~ gulp打包工具,，webpack研究了很久,，發(fā)現(xiàn)每增加一個頁面都要修改配置文件，這個太蛋疼,，遂放棄,。 開發(fā)流程
如果這次分享主要是講怎樣將node.js做為前端服務器來實現(xiàn)前后端分離的話那也沒什么好講的，看看淘寶UED的文章就好了,。前后端分離其實最大的問題是帶來溝通成本的上升,，具體來說就是接口的定義和調試。在上圖的傳統(tǒng)開發(fā)流程中,，接口的定義會放在接口服務器中,，然后前后端各自根據接口文檔造假數(shù)據進行本地調試，之后進行聯(lián)調,。這個環(huán)節(jié)就是前后端開始撕逼的時候了,，這個參數(shù)不對，那個返回值不對,，總之很浪費時間,。接下來看這個問題在我們項目中是怎么解決的~
前后端因為接口撕逼的問題一直存在，作為保守主義的我相信迭代開發(fā),，所以第一步做的只是增加了一個mock服務器,。這個服務器的神奇之處就是根據接口文檔自動生成假數(shù)據，實現(xiàn)了接口即API,，前端同學再也不用把數(shù)據寫死進行測試了,。沒辦法，誰叫我是前端開發(fā),，首先想到自己人,，嘿嘿~當然這個只在一定程度上有利于前端開發(fā)，后端的接口和文檔不一致聯(lián)調時也會出現(xiàn)問題,。怎么辦,？
偶然在破浪大神的博客上看到老馬的一篇專門講前后端分離的文章,，其中一個重要的概念就是契約測試也叫雙邊測試吧,。核心概念就是為了解決遠程聯(lián)調的問題。對前后端的參數(shù)都進行校驗,，要求大家按照接口文檔進行開發(fā),。受其啟發(fā)，加入json-schema規(guī)則，實現(xiàn)了對http請求的參數(shù)校驗,，誰不按規(guī)矩來誰改,。
這個redmine是我們最早的接口文檔管理器，除了記錄和查看功能再無其他作用,。
swagger號稱世界最流行的接口文檔服務器,，界面美觀，插件也還比較多,，可以針對后端語言直接生成測試代碼,。不過部署的時候始終沒玩懂，而且yaml格式不如json習慣,，放棄了它,。
這就是現(xiàn)在我們項目上用的文檔服務器和mock服務器，基于MEAN技術實現(xiàn)的服務器,，基本功能： 利用mockjs插件,，可以動態(tài)生成隨機數(shù)據基于json-schema對接口參數(shù)實行校驗和接口測試，并保存測試狀態(tài)和接口響應時間,。簡單的json編輯器帶有登陸校驗功能,，可登陸后進行接口調試mock服務器按照api服務器來響應請求，接口更新時自動更新 一些問題
node.js是前端工程師的翅膀,，而插上翅膀是變成天使還是變成惡魔,？這個要看能不能解決的使用它時帶來的問題了。 首先前端的工作量毫無疑問地會增加,，但溝通成本會降低,。node.js單線程的服務器穩(wěn)定性確實不夠好，不過代碼的健壯性和完善的日志可以有效的規(guī)避,?；卣{。這個問題解決方法就太多了,，node.js的q/async模塊以及ES6/ES7,。node.js調試。雖然我一直排斥IDE,，但不得不承認webstorm在調試上確實很方便,。我用的node-inspector也還湊合，界面類似chrome開發(fā)者工具,，看上去挺熟悉的,。
如果對于后端程序員，更加應該擁簇node.js了,。接口整合的工作交給了前端服務器進行處理,，同時和前端耦合度大大降低,，工作量和工作效率都減少了。
心得體會有兩點 node.js的使用雖然有一定的學習成本,，但對于前端開發(fā)人員還是很友好的,。而且前端使用node.js的話，無論是技術含量還是工作量都會有所提升,，從而提升了崗位的重要性,。當前端開發(fā)人員能創(chuàng)造更多價值的時候才有資格要求更高的薪水~工作中建議少提建議多給可行性方案，同時進行技術預研而不是寫個簡單的helloworld,。 總結 可能有人說你介紹的這一套東西這么復雜,，用起來太麻煩了，還不如面對面溝通,。 對于這樣的質疑我只能用騰訊高級UI工程師余果在《web全棧工程師的自我修養(yǎng)》中講到的一個例子,。有一次他電面一家小公司的前端負責人問他怎么管理代碼時，對方說直接用ftp上傳,，同時抱怨手下人老是更新錯代碼,，又問他為什么不用svn或git，他說還不如手動更新方便,。 這個故事的道理就是我面對質疑的回答~ |
|
|
