基於NodeJS的先後端分離

簡介

在制定網站的總體框架時候，很是強調架構的上的先後端分離。這種分離意味着數據層、複雜業務邏輯與前端展示和交互的層次分離。

WHY (爲何要這麼作)

• 清晰的結構。先後端的融合是經過一套中間層的協議來完成的，實現上是後端對前端只露出API接口。在軟件設計層面，流動的數據，讓先後端能夠獨立的專一的作本身，而不是被對方所綁架。

• 同步開發。不被對方所綁架，就意味着，在開發時，經過事先的約定，前端和後端能夠同步進行。而交接層經過單元測試保證交付。能夠縮短項目進度

在作此次設計以前，着重參考了淘寶大牛們的中途島方案。感謝他們讓我走出了一套代碼吃遍先後端的理想迴歸了現實。

REQUIREMENT (需求)

在作url設計的時候，提出了這樣一個概念：

當瀏覽以服務端渲染頁面爲主時，url的path部分由服務端負責解析、渲染最後輸出頁面，當到達瀏覽器端，js負責渲染hash部分的數據和視圖

當頁面的形式以webaap爲主時，url的path和hash部分都由js負責渲染

在這樣的過程當中，力圖解決兩個問題：

• webapp的seo問題

• url追溯問題

TODO (作了什麼)

與淘寶Midway的思想一致，在瀏覽器端和服務端，共享是模板，基於此也參考低版本瀏覽器的一些性能問題，前端選型上，使用了CanJS，由於其模板引擎是ejs能夠被expressjs兼容，同時CanJS在低版本瀏覽器上的新能是非突出，因此選型用了CanJS

CanJS中View的生命週期擴展

如上圖所示，默認的生命週期只有start和end兩個階段，咱們顯示的加入了render和supplement兩個階段。

• render定義爲主渲染階段，這部分能夠在瀏覽器端進行渲染，也能夠在服務端端進行渲染，服務端渲染完成以後，會在根節點上加入data-status="ready"的屬性，來標示渲染完畢，當瀏覽器檢測到這個屬性時，就不會重複渲染。

• supplement定義爲補充渲染階段，這部分在瀏覽器端進行渲染，其數據參數經過hash被傳入

EXAMPLE (案例)

sf-haitao-webapp-seo這個項目的代碼就是具體的案例，因爲在實踐初期，代碼變更會很是快。

啓動代碼以後，分別訪問兩個連接：

• 由服務端進行渲染: http://127.0.0.1:3000/paint/2023013

• 由瀏覽器負責渲染: http://127.0.0.1:3000/render/2023013

注：這裏的2023013是豆瓣裏面惟一能夠隨意訪問的，請不要用其餘的id吧，見諒

兩個連接訪問以後，在尾巴後加入以下hash，看看會有什麼結果

#!case/29

HOWTO (如何去作)

1. 須要安裝NodeJS環境和Bower加載器

2. Clone代碼到本，默認目錄爲sf-haitao-webapp-seo

3. 進入目錄，安裝依賴庫

   npm install

   bower install

4. 在根目錄上運行

   node bin\www

項目地址： https://github.com/leewind/sf-haitao-webapp-seo

DISCUSS (討論)

思考這樣一個問題：既然不糾結於服務端和瀏覽器端代碼一致，那麼是否是有可能用其餘的替代Nodejs來作服務端渲染的工做，好比：Sprint MVC、.Net MVC、Python Tornado？

在CanJS中默認推薦兩種模板：ejs和mustache。我沒有找到其餘語言對於ejs模板的支持，可是mustache在其餘語言上的應用作的很是的好，具體能夠參考mustache官方站點

那反過來想，有沒有其餘的語言模板能夠在Nodejs環境下可使用的，而後我找到了Velocity.js，我想若是前端CanJS能夠兼容Velocity.js的模板，那麼在作渲染的時候，可能我有第二套方案：用Java Velocity去作render邏輯的渲染！

對於mustache用於多語言平臺的拓展和Velocity對CanJS的擴展是我下一步的實踐目標

REFERENCE (參考)

• 深刻詳解前端輕量級MVC框架新貴CanJS(1)

• 也談基於NodeJS的全棧式開發（基於NodeJS的先後端分離）

• 先後端分離模式下的安全解決方案