摘要：服務端渲染兩種方式根據(jù)上文介紹對服務端渲染利弊有所了解，我們可以根據(jù)利弊權衡取舍，最近在做服務端渲染的項目，找到多種服務端渲染解決方案，大致分為兩類。第一種方式傳統(tǒng)方式服務端渲染，解決用戶體驗和更好的，有諸多工具使用這種方式如的的等。

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

使用 React 構建客戶端應用程序，默認情況下，可以在瀏覽器中輸出 React 組件，進行生成 DOM 和操作 DOM。React 也可以在服務端通過 Node.js 轉換成 HTML，直接在瀏覽器端“呈現(xiàn)”處理好的 HTML 字符串，這個過程可以被認為 “同構”，因為應用程序的大部分代碼都可以在服務器和客戶端上運行。

與傳統(tǒng) SPA(Single Page Application - 單頁應用程序)相比，服務器端渲染(SSR)的優(yōu)勢主要在于：

更好的 SEO，由于搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。

更好的用戶體驗，對于緩慢的網(wǎng)絡情況或運行緩慢的設備，加載完資源瀏覽器直接呈現(xiàn)，無需等待所有的 JavaScript 都完成下載并執(zhí)行，才顯示服務器渲染的HTML。

由于服務端與瀏覽器客戶端環(huán)境區(qū)別，選擇一些開源庫需要注意，部分庫是無法在服務端執(zhí)行，比如你有 document、window 等對象獲取操作，都會在服務端就會報錯，所以在選擇的開源庫要做甄別。

使用服務端渲染，比如要起一個專門在服務端渲染的服務，與之前，只管客戶端所需靜態(tài)資源不同，你還需要 Node.js 服務端的和運維部署的知識，對你所需要掌握的知識點要求更多

服務器需要更多的負載，在 Node.js 中完成渲染，由于 Node.js 的原因大量的CPU資源會被占用。

下文介紹一種服務端渲染的“操作”，這個新的操作擁有新的問題，比如API請求兩次，各種服務端問題，你就無能為力了，因為這個新的工具用Golang寫的，你的團隊或者是你，需要了解一下Golang，你說氣不氣人又要多學東西。

根據(jù)上文介紹對服務端渲染利弊有所了解，我們可以根據(jù)利弊權衡取舍，最近在做服務端渲染的項目，找到多種服務端渲染解決方案，大致分為兩類。

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

有些工具將 webpack 運行在服務端生產環(huán)境，實時編譯，將編譯結果緩存起來，這都還是傳統(tǒng)的方式，只不過將 webpack 運行在服務端實時編譯，還是開發(fā)環(huán)境編譯預編譯好的問題。

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

服務器 bundle 用于服務器端渲染(SSR)

客戶端 bundle 給瀏覽器加載，瀏覽器通過 bundle 加載更多其它模塊(chunk)js

資源映射文件 assets.json 則是，服務器 bundle 在準備所需 HTML，需要預插入那些模塊(chunk)js，和CSS，這只是提高用戶體驗。

具體使用方法，可以看我最近造的個輪子 kkt-ssr，這個輪子將工具的部分封裝起來，你只需要寫業(yè)務代碼，和少量的服務端渲染代碼即可，還附贈十幾個示例，加上一個相對比較完善的示例react-router+rematch，類似于 next.js，但是有相當大的區(qū)別。

這是一種創(chuàng)新的方法，前端單頁面應用，以前怎么玩兒，現(xiàn)在還怎么玩兒，多的一步是，你得先訪問一個Rendora的服務，在前面攔截是否需要服務端渲染。下圖為官方圖：

這種方式原本只是個想法，想法是前端不用管服務端渲染的事兒了，不就是解決SEO？，這些爬蟲過來的時候，可以通過頭信息判斷，寫個服務，然后將需要的內容給爬蟲就可以了，昨天恰巧在GitHub的趨勢榜上，恰巧看到 Rendora 個工具，也就那么巧，剛好思路一致，這個工具主要為網(wǎng)絡爬蟲提供零配置服務器端渲染，以便毫不費力地改進在現(xiàn)代Javascript框架（如React.js，Vue.js，Angular.js等）中開發(fā)的網(wǎng)站的SEO問題。

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

請求被列入白名單作為SSR的候選者(即過濾后的Get請求)，Rendora 會指示無頭Chrome實例請求相應的頁面，呈現(xiàn)它，并返回包含最終服務器端的響應呈現(xiàn)出HTML。通常只需要將百度、谷歌、必應爬蟲等網(wǎng)絡抓取工具列入白名單即可。

未列入白名單(即請求不是GET請求或未通過任何過濾器)，Rendora將只是充當反向HTTP代理，只是按原樣傳送請求和響應。

Rendora可以看作是位于后端服務器（例如Node.js / Express.js，Python / Django等等）之間的反向HTTP代理服務器，也可能是你的前端代理服務器（例如nginx，traefik，apache等），

Rendora 是我見過的接近于完美的動態(tài)渲染器，提供零配置服務器端渲染

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

Rendora，新的方式非常厲害，有很多優(yōu)勢：

方便遷移老的項目，前端和后端代碼不需要更改。

可能更快的性能，資源(CPU)消耗可能更少，Golang編寫的二進制文件

多種緩存策略

已經(jīng)擁有 docker 容器方案

此工具，服務端渲染的頁面需要緩存，緩存引發(fā)的小問題就是

通過緩存解決，性能問題和調用API兩次的問題，服務端渲染，客戶端展示渲染，平常調用一次API，現(xiàn)在調用了兩次。

被緩存的頁面，不能及時清理，比如網(wǎng)站發(fā)現(xiàn)用戶發(fā)了不良信息，需要清理，就需要清理緩存頁面了。

如果想提高用戶體驗，瀏覽器端一些頁面需要服務端渲染，這個時候服務端需要請求API，就會有權限問題，或者直接從緩存里面讀取的HTML，到瀏覽器客戶端，可能會有服務端和瀏覽器端渲染不一致的錯誤。

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

感覺我的輪子 kkt-ssr 好像白寫了一樣，經(jīng)過分析發(fā)現(xiàn)目前還有一點作用吧，至少解決了不多調用一次API，和API調用權限問題導致渲染不一致的問題。但是我更推薦Rendora的方式，這將是未來。