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

什么是服務(wù)器端渲染

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

為什么使用服務(wù)器端渲染

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

• 更好的 SEO，由于搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁(yè)面。
• 更好的用戶體驗(yàn)，對(duì)于緩慢的網(wǎng)絡(luò)情況或運(yùn)行緩慢的設(shè)備，加載完資源瀏覽器直接呈現(xiàn)，無(wú)需等待所有的 JavaScript 都完成下載并執(zhí)行，才顯示服務(wù)器渲染的HTML。

服務(wù)端渲染的弊端

• 由于服務(wù)端與瀏覽器客戶端環(huán)境區(qū)別，選擇一些開源庫(kù)需要注意，部分庫(kù)是無(wú)法在服務(wù)端執(zhí)行，比如你有 document、window 等對(duì)象獲取操作，都會(huì)在服務(wù)端就會(huì)報(bào)錯(cuò)，所以在選擇的開源庫(kù)要做甄別。
• 使用服務(wù)端渲染，比如要起一個(gè)專門在服務(wù)端渲染的服務(wù)，與之前，只管客戶端所需靜態(tài)資源不同，你還需要 Node.js 服務(wù)端的和運(yùn)維部署的知識(shí)，對(duì)你所需要掌握的知識(shí)點(diǎn)要求更多
• 服務(wù)器需要更多的負(fù)載，在 Node.js 中完成渲染，由于 Node.js 的原因大量的CPU資源會(huì)被占用。
• 下文介紹一種服務(wù)端渲染的“操作”，這個(gè)新的操作擁有新的問(wèn)題，比如API請(qǐng)求兩次，各種服務(wù)端問(wèn)題，你就無(wú)能為力了，因?yàn)檫@個(gè)新的工具用Golang寫的，你的團(tuán)隊(duì)或者是你，需要了解一下Golang，你說(shuō)氣不氣人又要多學(xué)東西。

服務(wù)端渲染兩種方式

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

第一種方式

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

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

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

• 服務(wù)器 bundle 用于服務(wù)器端渲染(SSR)
• 客戶端 bundle 給瀏覽器加載，瀏覽器通過(guò) bundle 加載更多其它模塊(chunk)js
• 資源映射文件 assets.json 則是，服務(wù)器 bundle 在準(zhǔn)備所需 HTML，需要預(yù)插入那些模塊(chunk)js，和CSS，這只是提高用戶體驗(yàn)。

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

第二種方式

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

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

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

1. 請(qǐng)求被列入白名單作為SSR的候選者(即過(guò)濾后的Get請(qǐng)求)，Rendora 會(huì)指示無(wú)頭Chrome實(shí)例請(qǐng)求相應(yīng)的頁(yè)面，呈現(xiàn)它，并返回包含最終服務(wù)器端的響應(yīng)呈現(xiàn)出HTML。通常只需要將百度、谷歌、必應(yīng)爬蟲等網(wǎng)絡(luò)抓取工具列入白名單即可。
2. 未列入白名單(即請(qǐng)求不是GET請(qǐng)求或未通過(guò)任何過(guò)濾器)，Rendora將只是充當(dāng)反向HTTP代理，只是按原樣傳送請(qǐng)求和響應(yīng)。

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

Rendora 是我見(jiàn)過(guò)的接近于完美的動(dòng)態(tài)渲染器，提供零配置服務(wù)器端渲染

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

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

• 方便遷移老的項(xiàng)目，前端和后端代碼不需要更改。
• 可能更快的性能，資源(CPU)消耗可能更少，Golang編寫的二進(jìn)制文件
• 多種緩存策略
• 已經(jīng)擁有 docker 容器方案

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

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

被緩存的頁(yè)面，不能及時(shí)清理，比如網(wǎng)站發(fā)現(xiàn)用戶發(fā)了不良信息，需要清理，就需要清理緩存頁(yè)面了。如果想提高用戶體驗(yàn)，瀏覽器端一些頁(yè)面需要服務(wù)端渲染，這個(gè)時(shí)候服務(wù)端需要請(qǐng)求API，就會(huì)有權(quán)限問(wèn)題，或者直接從緩存里面讀取的HTML，到瀏覽器客戶端，可能會(huì)有服務(wù)端和瀏覽器端渲染不一致的錯(cuò)誤。

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

總結(jié)

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

補(bǔ)充：

同構(gòu)方案

這里我們采用React技術(shù)體系做同構(gòu)，由于React本身的設(shè)計(jì)特點(diǎn)，它是以Virtual DOM的形式保存在內(nèi)存中，這是服務(wù)端渲染的前提。

對(duì)于客戶端，通過(guò)調(diào)用ReactDOM.render方法把Virtual DOM轉(zhuǎn)換成真實(shí)DOM最后渲染到界面。

import { render } from 'react-dom'
import App from './App'

render(<App />, document.getElementById('root'))

對(duì)于服務(wù)端，通過(guò)調(diào)用ReactDOMServer.renderToString方法把Virtual DOM轉(zhuǎn)換成HTML字符串返回給客戶端，從而達(dá)到服務(wù)端渲染的目的。

import { renderToString } from 'react-dom/server'
import App from './App'

async function(ctx) {
  await ctx.render('index', {
    root: renderToString(<App />)
  })
}

狀態(tài)管理方案

我們選擇Redux來(lái)管理React組件的非私有組件狀態(tài)，并配合社區(qū)中強(qiáng)大的中間件Devtools、Thunk、Promise等等來(lái)擴(kuò)充應(yīng)用。當(dāng)進(jìn)行服務(wù)端渲染時(shí)，創(chuàng)建store實(shí)例后，還必須把初始狀態(tài)回傳給客戶端，客戶端拿到初始狀態(tài)后把它作為預(yù)加載狀態(tài)來(lái)創(chuàng)建store實(shí)例，否則，客戶端上生成的markup與服務(wù)端生成的markup不匹配，客戶端將不得不再次加載數(shù)據(jù)，造成沒(méi)必要的性能消耗。

服務(wù)端

import { renderToString } from 'react-dom/server'
import { Provider } from 'react-redux'
import { createStore } from 'redux'
import App from './App'
import rootReducer from './reducers'

const store = createStore(rootReducer)

async function(ctx) {
  await ctx.render('index', {
    root: renderToString(
      <Provider store={store}>
        <App />
      </Provider>
    ),
    state: store.getState()
  })
}

HTML

<body>
  <div id="root"><%- root %></div>
  <script>
    window.REDUX_STATE = <%- JSON.stringify(state) %>
  </script>
</body>

客戶端

import { render } from 'react-dom'
import { Provider } from 'react-redux'
import { createStore } from 'redux'
import App from './App'
import rootReducer from './reducers'

const store = createStore(rootReducer, window.REDUX_STATE)

render(
  <Provider store={store}>
    <App />
  </Provider>, 
  document.getElementById('root')
)

路由方案

客戶端路由的好處就不必多說(shuō)了，客戶端可以不依賴服務(wù)端，根據(jù)hash方式或者調(diào)用history API，不同的URL渲染不同的視圖，實(shí)現(xiàn)無(wú)縫的頁(yè)面切換，用戶體驗(yàn)極佳。但服務(wù)端渲染不同的地方在于，在渲染之前，必須根據(jù)URL正確找到相匹配的組件返回給客戶端。

React Router為服務(wù)端渲染提供了兩個(gè)API：

• - match 在渲染之前根據(jù)URL匹配路由組件
• - RoutingContext 以同步的方式渲染路由組件

服務(wù)端

import { renderToString } from 'react-dom/server'
import { Provider } from 'react-redux'
import { createStore } from 'redux'
import { match, RouterContext } from 'react-router'
import rootReducer from './reducers'
import routes from './routes'

const store = createStore(rootReducer)

async function clientRoute(ctx, next) {
  let _renderProps

  match({routes, location: ctx.url}, (error, redirectLocation, renderProps) => {
    _renderProps = renderProps
  })

  if (_renderProps) {
    await ctx.render('index', {
      root: renderToString(
        <Provider store={store}>
          <RouterContext {..._renderProps} />
        </Provider>
      ),
      state: store.getState()
    })
  } else {
    await next()
  }
}

客戶端

import { Route, IndexRoute } from 'react-router'
import Common from './Common'
import Home from './Home'
import Explore from './Explore'
import About from './About'

const routes = (
  <Route path="/" component={Common}>
    <IndexRoute component={Home} />
    <Route path="explore" component={Explore} />
    <Route path="about" component={About} />
  </Route>
)

export default routes

靜態(tài)資源處理方案

在客戶端中，我們使用了大量的ES6/7語(yǔ)法，jsx語(yǔ)法，css資源，圖片資源，最終通過(guò)webpack配合各種loader打包成一個(gè)文件最后運(yùn)行在瀏覽器環(huán)境中。但是在服務(wù)端，不支持import、jsx這種語(yǔ)法，并且無(wú)法識(shí)別對(duì)css、image資源后綴的模塊引用，那么要怎么處理這些靜態(tài)資源呢？我們需要借助相關(guān)的工具、插件來(lái)使得Node.js解析器能夠加載并執(zhí)行這類代碼，下面分別為開發(fā)環(huán)境和產(chǎn)品環(huán)境配置兩套不同的解決方案。

開發(fā)環(huán)境

首先引入babel-polyfill這個(gè)庫(kù)來(lái)提供regenerator運(yùn)行時(shí)和core-js來(lái)模擬全功能ES6環(huán)境。

引入babel-register，這是一個(gè)require鉤子，會(huì)自動(dòng)對(duì)require命令所加載的js文件進(jìn)行實(shí)時(shí)轉(zhuǎn)碼，需要注意的是，這個(gè)庫(kù)只適用于開發(fā)環(huán)境。

引入css-modules-require-hook，同樣是鉤子，只針對(duì)樣式文件，由于我們采用的是CSS Modules方案，并且使用SASS來(lái)書寫代碼，所以需要node-sass這個(gè)前置編譯器來(lái)識(shí)別擴(kuò)展名為.scss的文件，當(dāng)然你也可以采用LESS的方式，通過(guò)這個(gè)鉤子，自動(dòng)提取className哈希字符注入到服務(wù)端的React組件中。

引入asset-require-hook，來(lái)識(shí)別圖片資源，對(duì)小于8K的圖片轉(zhuǎn)換成base64字符串，大于8k的圖片轉(zhuǎn)換成路徑引用。

// Provide custom regenerator runtime and core-js
require('babel-polyfill')

// Javascript required hook
require('babel-register')({presets: ['es2015', 'react', 'stage-0']})

// Css required hook
require('css-modules-require-hook')({
  extensions: ['.scss'],
  preprocessCss: (data, filename) =>
    require('node-sass').renderSync({
      data,
      file: filename
    }).css,
  camelCase: true,
  generateScopedName: '[name]__[local]__[hash:base64:8]'
})

// Image required hook
require('asset-require-hook')({
  extensions: ['jpg', 'png', 'gif', 'webp'],
  limit: 8000
})

產(chǎn)品環(huán)境

對(duì)于產(chǎn)品環(huán)境，我們的做法是使用webpack分別對(duì)客戶端和服務(wù)端代碼進(jìn)行打包?？蛻舳舜a打包這里不多說(shuō)，對(duì)于服務(wù)端代碼，需要指定運(yùn)行環(huán)境為node，并且提供polyfill，設(shè)置__filename和__dirname為true，由于是采用CSS Modules，服務(wù)端只需獲取className，而無(wú)需加載樣式代碼，所以要使用css-loader/locals替代css-loader加載樣式文件

// webpack.config.js
{
  target: 'node',
  node: {
    __filename: true,
    __dirname: true
  },
  module: {
    loaders: [{
      test: /\.js$/,
      exclude: /node_modules/,
      loader: 'babel',
      query: {presets: ['es2015', 'react', 'stage-0']}
    }, {
      test: /\.scss$/,
      loaders: [
        'css/locals?modules&camelCase&importLoaders=1&localIdentName=[hash:base64:8]',
        'sass'
      ]
    }, {
      test: /\.(jpg|png|gif|webp)$/,
      loader: 'url?limit=8000'
    }]
  }
}

動(dòng)態(tài)加載方案

對(duì)于大型Web應(yīng)用程序來(lái)說(shuō)，將所有代碼打包成一個(gè)文件不是一種優(yōu)雅的做法，特別是對(duì)于單頁(yè)面應(yīng)用，用戶有時(shí)候并不想得到其余路由模塊的內(nèi)容，加載全部模塊內(nèi)容，不僅增加用戶等待時(shí)間，而且會(huì)增加服務(wù)器負(fù)荷。Webpack提供一個(gè)功能可以拆分模塊，每一個(gè)模塊稱為chunk，這個(gè)功能叫做Code Splitting。你可以在你的代碼庫(kù)中定義分割點(diǎn)，調(diào)用require.ensure，實(shí)現(xiàn)按需加載，而對(duì)于服務(wù)端渲染，require.ensure是不存在的，因此需要判斷運(yùn)行環(huán)境，提供鉤子函數(shù)。

重構(gòu)后的路由模塊為

// Hook for server
if (typeof require.ensure !== 'function') {
  require.ensure = function(dependencies, callback) {
    callback(require)
  }
}

const routes = {
  childRoutes: [{
    path: '/',
    component: require('./common/containers/Root').default,
    indexRoute: {
      getComponent(nextState, callback) {
        require.ensure([], require => {
          callback(null, require('./home/containers/App').default)
        }, 'home')
      }
    },
    childRoutes: [{
      path: 'explore',
      getComponent(nextState, callback) {
        require.ensure([], require => {
          callback(null, require('./explore/containers/App').default)
        }, 'explore')
      }
    }, {
      path: 'about',
      getComponent(nextState, callback) {
        require.ensure([], require => {
          callback(null, require('./about/containers/App').default)
        }, 'about')
      }
    }]
  }]
}

export default routes

優(yōu)化方案

vendor: ['react', 'react-dom', 'redux', 'react-redux']

所有js模塊以chunkhash方式命名

output: {
  filename: '[name].[chunkhash:8].js',
  chunkFilename: 'chunk.[name].[chunkhash:8].js',
}

提取公共模塊，manifest文件起過(guò)渡作用

new webpack.optimize.CommonsChunkPlugin({
  names: ['vendor', 'manifest'],
  filename: '[name].[chunkhash:8].js'
})

提取css文件，以contenthash方式命名

new ExtractTextPlugin('[name].[contenthash:8].css')

模塊排序、去重、壓縮

new webpack.optimize.OccurrenceOrderPlugin(), // webpack2 已移除
new webpack.optimize.DedupePlugin(), // webpack2 已移除
new webpack.optimize.UglifyJsPlugin({
  compress: {warnings: false},
  comments: false
})

使用babel-plugin-transform-runtime取代babel-polyfill，可節(jié)省大量文件體積
需要注意的是，你不能使用最新的內(nèi)置實(shí)例方法，例如數(shù)組的includes方法

{
  presets: ['es2015', 'react', 'stage-0'],
  plugins: ['transform-runtime']
}

最終打包結(jié)果

部署方案

pm2 start ./server.js -i 0

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。