React 服务端渲染

服务端渲染的优势在于：由中间层( node端 )为客户端请求初始数据、并由node渲染页面

什么是服务器端渲染

使用 React 构建客户端应用程序，默认情况下，可以在浏览器中输出 React 组件，进行生成 DOM 和操作 DOM。React 也可以在服务端通过 Node.js 转换成 HTML，直接在浏览器端“呈现”处理好的 HTML 字符串，这个过程可以被认为 “同构”，因为应用程序的大部分代码都可以在服务器和客户端上运行。

简单理解是将组件或页面通过服务器生成html字符串，再发送到浏览器，最后将静态标记"混合"为客户端上完全交互的应用程序

服务器渲染（后端渲染）
浏览器发送请求到服务器端，服务器端处理请求并处理好数据，然后生成html文件，并返回给浏览器。
传统的jsp、php都是属于服务器渲染。

客户端渲染（前端渲染）
服务器端处理请求后将数据返回给浏览器，浏览器通过拼接html字符串或者使用js模板引擎，或者React这类框架进行页面渲染,又称作 ： 局部渲染

为什么使用服务器端渲染

与传统 SPA(Single Page Application - 单页应用程序)相比，服务器端渲染(SSR)的优势主要在于：
更好的 SEO，服务器端渲染可以让搜索引擎更容易读取页面的meta信息以及其他SEO相关信息，大大增加网站在搜索引擎中的可见度
首次加载页面的速度加快， 更好的用户体验，用户在下载的已经是渲染好的页面了，打开速度比本地渲染快。
服务器端和客户端可以共享某些代码，避免重复定义。这样可以使结构更清晰，增加可维护性

前端渲染的优势：

局部更新页面，无需每次都进行完整页面请求
懒加载。页面初始时只加载可视区域内的数据，随着滚动等操作再加载其他数据
节约服务器成本
关注分离设计。服务器只用于访问数据库提供接口，前端关注展现。
富交互，使用 JS 实现各种酷炫效果---------------------

前后端拆分核心理念

前后端拆分，后端专注于数据接口服务，前端专注接口调用，页面渲染，双剑合璧，相得益彰。

SSR缺点

性能全都依赖于服务器
前端界面开发可操作性不高

CSR的缺点

不利于SEO–爬虫数据不好爬呀~~
整体加载完速度慢

时间耗时比较：
　　　　　　1. 数据请求：由服务端请求数据而不是客户端请求数据，这是“快”的一个主要原因。服务端在内网进行请求，数据响应速度快。客户端在不同网络环境进行数据请求，且外网http请求开销大，导致时间差（主要原因）。
　　　　　　2. 步骤：服务端是先请求数据然后渲染“可视”部分，而客户端是等待js代码下载、加载完成再请求数据、渲染。即：服务端渲染不用等待js代码下载完成再请求数据，并会返回一个已经有内容的页面。
　　　　　　3. 渲染性能：服务端性能比客户端高，渲染速度快( 猜测，该项数据不详 )。
　　　　　　4. 渲染内容：服务端渲染会把”可视“部分先渲染，然后交给客户端再作部分渲染。而客户端渲染，则是从无到有，需要经历完整的渲染步骤。

在今年举办的第12届D2前端大会上，笔者又听到了一个十分优秀的想法，并且阿里已经将之实现并申请了专利————智能降级策略。具体名字是不是这个已经记不太清了，大致内容是在同构的基础之上，优先使用服务端渲染，当访问量激增导致服务器负载超过设置的阈值之后，智能将部分渲染任务交给客户端处理，使服务器承受压力降低

服务端渲染两种方式

根据上文介绍对服务端渲染利弊有所了解，我们可以根据利弊权衡取舍，最近在做服务端渲染的项目，找到多种服务端渲染解决方案，大致分为两类。
第一种方式
传统方式服务端渲染，解决用户体验和更好的 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条路径：
请求被列入白名单作为SSR的候选者(即过滤后的Get请求)，Rendora 会指示无头Chrome实例请求相应的页面，呈现它，并返回包含最终服务器端的响应呈现出HTML。通常只需要将百度、谷歌、必应爬虫等网络抓取工具列入白名单即可。
未列入白名单(即请求不是GET请求或未通过任何过滤器)，Rendora将只是充当反向HTTP代理，只是按原样传送请求和响应。
Rendora可以看作是位于后端服务器（例如Node.js / Express.js，Python / Django等等）之间的反向HTTP代理服务器，也可能是你的前端代理服务器（例如nginx，traefik，apache等），
Rendora 是我见过的接近于完美的动态渲染器，提供零配置服务器端渲染
我们到底选择哪一种服务端渲染呢？
Rendora，新的方式非常厉害，有很多优势：
方便迁移老的项目，前端和后端代码不需要更改。
可能更快的性能，资源(CPU)消耗可能更少，Golang编写的二进制文件
多种缓存策略
已经拥有 docker 容器方案
此工具，服务端渲染的页面需要缓存，缓存引发的小问题就是
通过缓存解决，性能问题和调用API两次的问题，服务端渲染，客户端展示渲染，平常调用一次API，现在调用了两次。
被缓存的页面，不能及时清理，比如网站发现用户发了不良信息，需要清理，就需要清理缓存页面了。
如果想提高用户体验，浏览器端一些页面需要服务端渲染，这个时候服务端需要请求API，就会有权限问题，或者直接从缓存里面读取的HTML，到浏览器客户端，可能会有服务端和浏览器端渲染不一致的错误。