React 服務端渲染方案完美的解決方案

最近在開發一個服務端渲染工具，經過一篇小文大體介紹下服務端渲染，和服務端渲染的方式方法。在此文後面有兩中服務端渲染方式的構思，根據你對服務端渲染的利弊權衡，你會選擇哪種服務端渲染方式呢？

什麼是服務器端渲染

使用 React 構建客戶端應用程序，默認狀況下，能夠在瀏覽器中輸出 React 組件，進行生成 DOM 和操做 DOM。React 也能夠在服務端經過 Node.js 轉換成 HTML，直接在瀏覽器端「呈現」處理好的 HTML 字符串，這個過程能夠被認爲 「同構」，由於應用程序的大部分代碼均可以在服務器和客戶端上運行。

爲何使用服務器端渲染

與傳統 SPA(Single Page Application - 單頁應用程序)相比，服務器端渲染(SSR)的優點主要在於：

1. 更好的 SEO，因爲搜索引擎爬蟲抓取工具能夠直接查看徹底渲染的頁面。
2. 更好的用戶體驗，對於緩慢的網絡狀況或運行緩慢的設備，加載完資源瀏覽器直接呈現，無需等待全部的 JavaScript 都完成下載並執行，才顯示服務器渲染的HTML。

服務端渲染的弊端

1. 因爲服務端與瀏覽器客戶端環境區別，選擇一些開源庫須要注意，部分庫是沒法在服務端執行，好比你有 document、window 等對象獲取操做，都會在服務端就會報錯，因此在選擇的開源庫要作甄別。

2. 使用服務端渲染，好比要起一個專門在服務端渲染的服務，與以前，只管客戶端所需靜態資源不一樣，你還須要 Node.js 服務端的和運維部署的知識，對你所須要掌握的知識點要求更多

3. 服務器須要更多的負載，在 Node.js 中完成渲染，因爲 Node.js 的緣由大量的CPU資源會被佔用。

4. 下文介紹一種服務端渲染的「操做」，這個新的操做擁有新的問題，好比API請求兩次，各類服務端問題，你就無能爲力了，由於這個新的工具用Golang寫的，你的團隊或者是你，須要瞭解一下Golang，你說氣不氣人又要多學東西。

服務端渲染兩種方式

根據上文介紹對服務端渲染利弊有所瞭解，咱們能夠根據利弊權衡取捨，最近在作服務端渲染的項目，找到多種服務端渲染解決方案，大體分爲兩類。

第一種方式

傳統方式服務端渲染，解決用戶體驗和更好的 SEO，有諸多工具使用這種方式如React的(Next.js)、Vue的(Nuxt.js)等。

有些工具將 webpack 運行在服務端生產環境，實時編譯，將編譯結果緩存起來，這都仍是傳統的方式，只不過將 webpack 運行在服務端實時編譯，仍是開發環境編譯預編譯好的問題。

我選擇了將 webpack 放在開發環境，只作開發打包的功能，打包 客戶端 bundle ， 服務端 bundle，資源映射文件 assets.json，CSS 等資源進行部署。

• 服務器 bundle 用於服務器端渲染(SSR)
• 客戶端 bundle 給瀏覽器加載，瀏覽器經過 bundle 加載更多其它模塊(chunk)js
• 資源映射文件 assets.json 則是，服務器 bundle 在準備所需 HTML，須要預插入那些模塊(chunk)js，和CSS，這只是提升用戶體驗。

具體使用方法，能夠看我最近造的個輪子 kkt-ssr，這個輪子將工具的部分封裝起來，你只須要寫業務代碼，和少許的服務端渲染代碼便可，還附贈十幾個示例，加上一個相對比較完善的示例react-router+rematch，相似於 next.js，可是有至關大的區別。

第二種方式

這是一種創新的方法，前端單頁面應用，之前怎麼玩兒，如今還怎麼玩兒，多的一步是，你得先訪問一個Rendora的服務，在前面攔截是否須要服務端渲染。下圖爲官方圖：

這種方式本來只是個想法，想法是前端不用管服務端渲染的事兒了，不就是解決SEO？，這些爬蟲過來的時候，能夠經過頭信息判斷，寫個服務，而後將須要的內容給爬蟲就能夠了，昨天恰巧在GitHub的趨勢榜上，恰巧看到 Rendora 個工具，也就那麼巧，恰好思路一致，這個工具主要爲網絡爬蟲提供零配置服務器端渲染，以便絕不費力地改進在現代Javascript框架（如React.js，Vue.js，Angular.js等）中開發的網站的SEO問題。

這種方式很是好，以前寫好的項目一句不用改，只需新起 Rendora 服務。對於來自前端服務器或外部的每一個請求(百度谷歌爬蟲)，Rendora會根據配置文件，根據頭，路徑來檢測或過濾，以肯定 Rendora 是否應該只傳遞從後端服務器返回的初始HTML或使用Chrome提供的無頭服務器端呈現的HTML。更具體地說，對於每一個請求，有2條路徑：

1. 請求被列入白名單做爲SSR的候選者(即過濾後的Get請求)，Rendora 會指示無頭Chrome實例請求相應的頁面，呈現它，並返回包含最終服務器端的響應呈現出HTML。一般只須要將百度、谷歌、必應爬蟲等網絡抓取工具列入白名單便可。
2. 未列入白名單(即請求不是GET請求或未經過任何過濾器)，Rendora將只是充當反向HTTP代理，只是按原樣傳送請求和響應。

Rendora能夠看做是位於後端服務器（例如Node.js / Express.js，Python / Django等等）之間的反向HTTP代理服務器，也多是你的前端代理服務器（例如nginx，traefik，apache等），

Rendora 是我見過的接近於完美的動態渲染器，提供零配置服務器端渲染

咱們到底選擇哪種服務端渲染呢？

Rendora，新的方式很是厲害，有不少優點：

1. 方便遷移老的項目，前端和後端代碼不須要更改。
2. 可能更快的性能，資源(CPU)消耗可能更少，Golang編寫的二進制文件
3. 多種緩存策略
4. 已經擁有 docker 容器方案

此工具，服務端渲染的頁面須要緩存，緩存引起的小問題就是

1. 經過緩存解決，性能問題和調用API兩次的問題，服務端渲染，客戶端展現渲染，日常調用一次API，如今調用了兩次。
2. 被緩存的頁面，不能及時清理，好比網站發現用戶發了不良信息，須要清理，就須要清理緩存頁面了。
3. 若是想提升用戶體驗，瀏覽器端一些頁面須要服務端渲染，這個時候服務端須要請求API，就會有權限問題，或者直接從緩存裏面讀取的HTML，到瀏覽器客戶端，可能會有服務端和瀏覽器端渲染不一致的錯誤。

若是上面兩種方式不在你的考慮範疇以內，那Rendora將是你完美的服務端渲染解決方案

總結

感受個人輪子 kkt-ssr 好像白寫了同樣，通過分析發現目前還有一點做用吧，至少解決了很少調用一次API，和API調用權限問題致使渲染不一致的問題。可是我更推薦Rendora的方式，這將是將來。

無論怎樣，輪子還須要Star的。😂