關於先後端同構，個人一點思路和心得（vue、nodejs、react、模版）

最近1年多，先後端同構慢慢變成一個流行詞，也許不少人還停留在先後端分離的最佳實踐道路上，但實際上又有一批人已經從簡單的服務端渲染走向探索最佳先後端同構方案的路上了。不過，我只是膜拜後者的過客。

 

雖然你們能夠去網絡搜索一下相關的概念解釋，但這裏我仍是簡單列舉一下，我理解的術語。

一、前端渲染：瀏覽器一側使用js，藉助模版或vue、react、angular等框架作的DOM結構生成。

二、後端渲染：服務器一側，使用php、nodejs等技術實現DOM結構生成，並在HTTP請求中返回給瀏覽器。

三、同構：瀏覽器一側的JS、HTML和服務器一側使用的JS、HTML使用一樣的開發結構，一樣的開發思路，一樣的開發模式，儘量實現代碼複用。

 

明確一點，做爲有追求的前端開發，咱們不該該盲目跟風，一切須要從實際出發。

 

那麼，首先，咱們須要瞭解爲何會有同構這個概念出現。

• Web開發的歷程是頗有趣的，最初php、asp的年代，一切內容都是服務器渲染的；
• 再後來爲了節省服務器資源，也更大限度利用客戶端緩存，又出現了先後端分離的模式，從而有了專業的前端開發和後臺開發。此時Web的特色是，js和html放到靜態目錄，也能夠CDN擴散，並以ajax方式獲取後臺的數據，在前端進行DOM組裝。這種開發方式沿用至今，這是一個好的工做模式，專業的人作專業的事，確實有利於工做效率提升。
• 再而，隨着nodejs的流行，前端jser們又開始蠢蠢欲動，嘗試吞併web接入這個後臺的前沿地盤，把後臺推到更後。大概2014年後，又出現了不少nodejs直出的方案，把頁面數據都一次在HTML的請求中返回，無需瀏覽器端再發起ajax獲取數據，並且服務器端把DOM結構都渲染好，瀏覽器按trunk直接作圖形渲染便可。不得不說，這個方案帶來了不少好處：首屏速度更快，瀏覽器更省電。固然，隨之而來的，就是更復雜的工做模式，jser須要作服務器端的邏輯，甚至一些代碼須要同時用在瀏覽器和nodejs上。
• 針對前邊的問題，同構的探討就開始了。。。

 

百度搜一下先後端同構，清一色的vue、react。這些確實是同構，但我認爲範圍太窄，同構不是框架帶來的問題，而是由於先後端獨立渲染這種架構層面帶來的問題。

固然，那些同構探討也是很是有價值的，但不在本文的討論範圍內，在這裏我更想表達一下，如何從實際項目需求的角度來看，找出本身所需的同構之道。

畢竟，要知道，同構不是爲了跟風耍酷，也不是爲了跳槽面試的時候博點好感。同構，是爲了提升用戶體驗的同時，提升團隊的工做效率。

 

接下來，我想根據項目的類型，說說本身的見解。

 

第一種，單頁面應用。

這個網站很相似一個APP，確實頗有必要作成單頁應用，有助於提升用戶體驗。

若是第一步選擇了單頁面應用，這裏就衍生了另外的問題——SEO。而react等框架作了服務器渲染，最大目的其實也是解決SEO。

既然瀏覽器端選擇了某個框架，例如React，而同時又考慮nodejs直出提升首屏的速度，那麼就沒有討價還價的餘地了，固然上react全家桶，先後端都用react。

這一種狀況，也就是網上搜索到的各類文章的狀況。

 

第二種，多頁面純數據展現，每一頁都比較簡單，沒有分屏的必要。

若是項目是這樣的狀況，使用nodejs直出，無非就是提升打開速度。而先後端基本八竿子打不着，最多就是一些工具函數（轉換一下日期格式，輸入框校驗）要作複用。

此時，不必大費周折去考慮什麼框架，因地制宜，想一想本身須要什麼便可。

要解決函數庫的先後端複用，能夠簡單作commonjs/window的兼容。

若是瀏覽器端的代碼比較多，就能夠考慮粒度化，使用webpack作瀏覽器端代碼打包，同時commonjs的寫法也能夠複用到nodejs層。

 

第三種，多頁面並且每一頁不是那麼簡單，首屏和次屏有一些HTML片斷（模版）須要複用

以前我所在項目組也遇到這樣的狀況，怎麼處理，一時之間爲了趕進度也沒太多考慮，使用了一些旁門左道，很差理解很差維護的方式，基於art-template作了一套有點奇怪的代碼，基本沒有同構一說。惟一同構的就是art-template支持瀏覽器和nodejs。

狀況怎麼噁心呢？大概是這樣：

• html模版，爲了複用，拆開爲多個小文件，若是先後端都用到，則一方面把這個模版內容不轉義不編譯地塞到最終HTML中，而另外一方面利用這個模版作nodejs渲染。前端ajax加載數據後渲染次屏時，再讀取HTML中某個模版作處理。
• 對於處理數據的js，可封裝部分，則利用跟剛纔第二種狀況相似的方式，作了commonjs/window的方式；很差封裝的部分，基本等於寫了兩份。
• 前端的js，動態塞到http返回中輸出的HTML中，可能有若干個js。

回頭想一想，當時狀況確實很糟，其實能夠利用已有的工具作得更優。

art-template是個好東西，這個不必去除。剛說的前兩點，代表這個項目有強烈的先後端代碼複用的必要，頗有須要使用更全面的同構方案。

如今我以爲有更好的方式：

• 用webpack作前端打包，這樣前端各類代碼和後臺代碼都是commonjs風格，能夠二合一。並且發佈前打包爲一個大js文件，也省去nodejs每次請求動態合併js的消耗。
• html模版發佈前先作預編譯，從html+模版語法，轉爲純js代碼，隨着webpack打包到瀏覽器端大js文件中。
• 後端和前端都用到的代碼，基於commonjs，儘量的抽離封裝。
• 最終合併的瀏覽器端大js仍是動態合併到首屏HTML中。

引入了webpack到瀏覽器端，就能很好的解決了原先html模版傳播的尷尬。而模塊風格的統一，也有利於先後端代碼更好的複用。

至於最終瀏覽器js是否打包到首屏HTML中，仍是單獨的部署CDN，這個其實就不是同構的問題了。不過對於移動端而言，仍是建議合併在一塊兒。

 

抽象一下，對於第三種項目狀況，跳出我原先的項目。我認爲，關鍵是要把先後端使用的模版統一爲一個方式引入。

 

第四種，仍是多頁面，瀏覽器端沒有模版拼裝的需求，第三種狀況的變種。

或者說，這個不是一個單獨的項目狀況，只是由於用的技術方案不一樣。跟第三種狀況同樣，但次屏的渲染，咱們不在瀏覽器端執行，而是繼續交給nodejs。瀏覽器端經過ajax把次屏html片斷拉取回來，而後直接塞到body中。並且，除此以外，瀏覽器端沒有用戶交互會致使已有的DOM發生重繪，或者極少內容重繪，不須要動用到模版。

在這個狀況下，瀏覽器端js更純粹的只關注事件處理。

我以爲這個又回到了第二種狀況，只須要簡單把一些庫函數封裝一下，作成先後端共用便可。

第四種狀況，由於完全拋棄了瀏覽器渲染，整個狀況就簡單多了，不須要考慮模版和不少邏輯js的先後端複用問題。