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的方式，这将是将来。

来源：