今天我们来学习了解一下三种不同的渲染机制，CSR，SSR和SRG。

在此之前，我们先来了解一下c端应用与b端应用

C端与B端

常见的产品可以分为B端(Business)和C端(Consumer)

B端通常为企业或商家为工作或商业目的而使用的系统型软件、工具或平台。面向的往往是企业或者是一些商家

而C端面向的则是消费者，用户这些群体。

所以我们在开发网站的时候，要考虑到受众的不同，开发出最合适的产品。

CSR

我们先来说说CSR

CSR的英文全称是Client-Side Rendering 是一种客户端渲染的模式，常见于传统的前后端分离的开发模式，渲染的工作交给客户端，而服务端只需要返回不加工的简单的HTML文件就可以。

这种模式常见于B端应用的开发。比如用一些工程化脚手架开发的SPA(single page web application)单页面应用就是这样的，与后台仅仅是数据的交互，不会再请求其它页面。浏览器一开始会加载必需的HTML、CSS和JavaScript，所有的操作都在这张页面上完成，都由JavaScript来控制。典型的单页面的开发框架包括我们常见的React,Vue2,Vue3,Angular等。

CSR的优点

CSR的开发模式有优点也有缺点，我们先来看一下他的优点，前后端分离的开发模式，让前端更专注于前端页面的开发与渲染，而后端则能更专注于逻辑的编写与数据的处理。同时代表的SPA应用，再首次请求之后，后续的不涉及请求数据的交互与渲染都会在客户端执行，大大减轻了服务器的压力。

不足与缺点

这种传统的前后端分离的模式有很多问题与缺点，还拿SPA来说，过长的首屏加载时间，用户在首次打开时需要等待较长的时间，这种致命的问题如果做B端开发还可以，因为B端应用往往具有指定性和唯一性，但是如果做面向用户的C端应用，就会给用户带来相对较差的体验与不满，不利于吸引用户。

同时这种传统的CSR的模式非常不利于SEO的推荐模式。

SEO

什么是SEO呢？

SEO就是指按照搜索引擎的算法，提升你的文章在搜索引擎中的自然排名

浏览器的推广程度，取决于搜索引擎对于站点检索的排名，搜索引擎是一种善意爬虫，他会爬取一些HTML，并根据用户输入的关键词对页面内容进行排序检索，最后返回搜索结果。

也就是说，纯从技术上来看，传统的前后端分离的设计模式并不利于SEO

那么CSR的模式在开发C端的时候这么多不足与缺陷，有没有相对更优的解决方案呢？接下来我们来继续了解一下SSR和SRG。

SSR

什么是SSR呢？SSR可以分为传统的SSR和同构SSR

传统的SSR

SSR本身并不是什么很新的，很稀奇的概念，传统的SSR甚至比前后端分离的CSR更加古老的多的多。

传统SSR的代表就是JSP,PHP。在渲染机制上，这种JSP/PHP采取的并不是和CSR一样的客户端渲染，而是采取了服务器端渲染的设计模式。这种模式下Java/php还需要负责渲染的逻辑，而前端只需要负责UI与交互就可以了。但是php/jsp采取的是前后端混合的开发模式，前后端代码写在一起，开发效率，维护效率，排查效率都比较低。越大的项目表现的越差。

同构SSR

接下来登场的是我们今天的主角，一种很新的SSR-----同构SSR

我们拿React框架举例子，所谓的同构SSR，即一套代码，不仅要在服务器上运行一遍，还要在客户端又运行一遍，前后端都会参与到渲染中去，而且还要保证首次渲染出来的HTML要一样。

同构SSR解决了传统SPA的首屏加载性能问题，极大程度上提高了用户的体验，同时同构SSR被更利于搜索引擎抓取，在技术层面上更容易，更大可能被推荐。同时服务器端天然的速度上的优势，也会更进一步加强性能与体验。现在很多大厂的C端web应用大多采取这种模式。比如我们现在在的稀土掘金，就是采取的这种开发模式。

提到了同构SSR，那么我们就不得不提到BFF层了。

BFF层

BFF，即 Backend For Frontend（服务于前端的后端）

BFF就是一个中间件的中间层，我们前端在同构SSR的设计模式中，在对接上可能不再和后端对接了。

而是和BFF层对接。

比如，我们前端要向不同的接口发送请求，根据不同服务的返回值渲染出不同的组件，这时访问页面的时候需要发送三个请求，为了保障 Android，iOS，以及 Web 端的不同需求，有时候会编写不同的接口API，有时候当值发生变化的时候，需要都做出修改，一些处理需求也需要都实现一遍。代价也比较大。

而BFF作为一个中间层，主要的业务场景请求转发、数据组织、接口适配、权鉴和SSR。BFF 层服务会更多地考虑接口在前端的使用，并且在服务端直接进行业务逻辑的处理，数据的整理和裁剪。

那么BFF具体需要做什么呢？

• 数据处理，会去裁剪，拼接数据，减少流量上的开销。
• 接口的整理，比传统前后端分离的模式更友好，不需要考虑系统后端的迁移。后端发生的变化都可以在 BFF 层做一些响应的修改。前端能更加更加专注于业务本身。
• 服务于多个终端，底层不需要考虑不同设备的兼容的逻辑的问题。

哇，BFF真香，那么我们如何实现BFF层呢？

实现上

BFF的实现上，最优解，也是几乎唯一的最优解就是Node.js大家族的那一套。go,Java等理论上也可以实现BFF层，但是一个是比较麻烦，另一个是可能出现一些问题。现在BFF层基本都是用Nodejs系列的东西进行开发。

先介绍一下几种常见前端框架的SSR的实现方式。

React的SSR一般依托于Next.js。

而Vue的SSR一般依托于Nuxt.js,下一篇文章可能带大家一起学习一下Nuxt.js。

SSG

最后说一下SSG,SSG:Static Site Generation。是一种静态站点生产的模式。

就是在构建的时候将结果页面的Html输出到磁盘上，每次直接将HTML发给客户端，整个都相当于一个静态资源了，一般可能会使用CDN，由不同区域的服务器组成分布式系统，将统一的，一致的页面发送给用户。

听了我的介绍之后你可能会产生一些疑问，如何保证用户喜好或是其他不同点的推送？有的用户喜欢前端，有的用户喜欢后端知识，如何呈现给他们不同的页面？答案是：做不到，SSG是一种静态站点的服务，适合发一些静态页面，就是大家看到都一样的页面，而对于上面的需求，同构SSR可能才是最优选择。

那么SSG还有什么用

因为想比SSR,这种模式不需要每次请求都由服务器处理了，服务器端的压力大大减轻，原本十台服务器做的事情，可能两台就能搞定了。不过这种SSG要考虑之前提到的缺陷。