「技术分享」SSR解决方案探索（ssr操作）

点击关注“八戒技术团队”，阅读更多技术干货

查看原文：【技术分享】SSR解决方案探索

基于以往的utopia框架技术栈已经较为老旧，utopia-next的研发已经开始啦，今天给大家分享一下新一代utopia框架中ssr模块的采坑之路，分享之前先来一起了解下ssr的相关概念吧：

相关概念

SSR：服务端渲染（Server Side Render），DOM树在服务端生成后返回给前端，当前DOM树中的数据都已在服务端中生成，返回给浏览器进行渲染，传统的服务端渲染方式：PHP/JSP以及template + data => html + 前端jquery，这种方式通过原生的js去绑定dom事件，部分代码无法在服务端执行，又称这是异构的服务渲染。

CSR：客户端渲染（Client Side Render），渲染过程交给浏览器处理，页面初始化加载的HTML中无内容，又嵌入的JS文件动态加载dom以及处理绑定事件。

同构：指组件能在服务端运行，生成html，再由客户端React/Vue接管页面交互（事件绑定）的服务端渲染方式。

在平时开发中我们享受着现代框架（React/Vue）给我们带来的便利，选择服务端渲染方式也是如此，同构渲染能够带给我们更好的体验，当然，每种技术方案都有利有弊，我们来了解下同构渲染中需要考量的一些地方：

同构开发的考量

1、前后端同构开发对前端开发者的心智要求较高，不同于传统的spa开发，服务端中获取数据的生命周期不同于客户端传统获取数据的生命周期，浏览器相关的接口无法在服务端中运行

2、复杂的打包构建，需要单独的client打包与server打包

3、服务端负载，这也是传统SSR开发的通病，当服务端压力较大时，服务端渲染能力也将受到影响，但同构的服务端渲染模式因其代码可以在客户端，服务端执行，可以做相对的转换，当服务器负载较高时，完全可以转为客户端渲染模式从而减轻服务端压力。

同构渲染的优点

1、更友好的SEO

2、更快的内容呈现

3、更优雅的渲染降级

4、服务端客户端代码共用

打包构建方案

使用webpack分别对客户端和服务端进行打包，服务端的包会被引入到服务端用来渲染html，同时客户端的包会被送到浏览器用于激活静态标记。

使用传统打包方案一直以来都有一个痛点，那就是项目体积大了之后客户端打包较慢。

基于vite的打包方案

vite是一种新型前端构建工具，能够显著提升前端开发体验

• 它基于原生ES模块提供了丰富的内建功能
• 内置了rollup进行打包，可输出用于生产环境的高度优化过的静态资源

vite的原生ES模块使你在开发环境可以直接引入没有打包过的esmodule规范代码，极大程度得提升开发环境的打包效率，但现版本的vite个人认为仍有部分需要考量。

1、对ssr的支持还在试验阶段。

2、rollup更适用于打库包而且不是需要更多代码分割处理的应用包

探索后的打包方案

基于传统SSR打包方按与vite打包方案的优缺点，我们决定结合两者有点来实现新的打包方案：

1、利用vite解决传统打包方案中客户端打包较慢的痛点；

2、服务端还是webpack打包（服务端本身打包体量很小，打包速度上不会因为项目体量过大而有很不好的打包体验）；

3、生产环境使用webpack5进行打包，webpack毕竟已经是老牌的打包工具，生态上更丰富，并且webpack5也引入了tree shaking支持。

具体实现

本地环境执行打包命令start，只会进行服务端打包；

生产环境执行打包命令build，进行客户端，服务端打包；

在服务端createSSRApp中嵌入vite的客户端热重载模块展开，同时我们将客户端入口文件经过vite处理过后引入到模板中，生产环境下客户端文件根据mainfest的映射依依引入。

大家可以看到生产环境下只引入了runtime~app.js，app.js，vendor.js文件，代码分割后的异步路由组件呢？

实际上异步组件通过webpack optimization处理过了，访问对应的路由会加载对应的文件，对应路由的js文件可以得到加载，但是在加载css文件的时候出了点问题，因为manifest生成的文件名是无规则的，我们并不清楚哪个路由应该引入哪个css，这时我们想到了webpack的webpackChunkName，我们通过一定的规则在路由里生成webpackChunkName，这样样式文件则通过当前路由下生成的webpackChunkName去manifest寻找对应的css文件。

作为通用ssr解决方案，我们需要提供vite中间件处理。

不同的打包命令，执行不同的打包方法，不同的打包方法执行各自的打包配置。

前面说的服务端需要打包的体量很小，为什么服务端体量小？回到服务端渲染的初衷，服务端渲染最核心的是处理首页的seo问题，也就是说我们只需要处理首页的渲染即可，因此我们需要把一些不需要webpack处理的外部依赖项external掉，我们通过webpack-node-externals来实现它。

渲染降级

在服务端渲染与客户端渲染的选择上，我们提供了渲染降级的能力，而不是简单从脚手架触发去实现客户端渲染打包发布的版本和服务端渲染打包发布的版本。 再来看下服务端渲染和客户端渲染的区别：

客户端渲染：客户端再请求时，服务端不做任何处理，直接将原文件返回给客户端（这里一般值一个静态html），然后再由html中的javascript去生成DOM

服务端渲染：服务端在接到客户端请求后，获取要渲染页面所要的数据，然后构建DOM后拼接到返回客户端的模板之中。

什么情况下需要降级

服务端渲染时，我们通常会遇到这样的一种情况，有一个服务器负载压力相对较高的路由，当次路由访问流量较高或出于其他什么原因导致报错时，该路由下渲染的模板返回也就会失败，这个时候给用户的反馈上往往就是一个白屏或返回的错误堆栈。

我们在服务端渲染出错时，回启用客户端渲染模式。

这样的降级处理不需要关心title，meta的部分，因为在我们的结构里layout部分始终是会渲染的，替换的仅仅只是children部分。

具体实现

我们提供了两种方式来降级处理：

1、在配置文件中定义renderMode，使整个系统使用csr渲染。

2、在请求中加入csr参数，可以使当前页面使用csr渲染模式。

处理完渲染的组件，再处理预处理数据，将本身在服务端渲染中的数据获取提到route中去执行。

这样我们便优雅得处理了渲染降级。

数据预获取

前面说的同构渲染要提供一个前后端都能执行其代码的能力，所以无论服务端渲染或者客户端渲染我们都提供数据预获取的能力，这样在渲染方式上才能自由切换并且不用耗费很大的心里，不用编写两套代码。

在SFC下我们提供了asyncData方法，该方法在服务端渲染时会在路由执行前完成，将获取到数据存储到pinia混入到客户端中去使用，同时在csr下，该方法会在route.vue挂载完成后去执行，并不会因为失去服务端能力而无法执行。

Title、Mate处理

在title、mate、link等嵌入html标签上，我们提供了一个useMain文件去进行配置处理，该文件逻辑将会在骨架的setup中（created）去执行，useHtml中提供了服务端请求上线文，配置中心参数以便于动态去修改title数据。

useMain中返回的数据将直接渲染到骨架模板上。

因为骨架app.vue与路由route.vue没有对外暴露的原因，所以我们通过useMain文件中的useComponent方法给用户提供全局注册组件、插件的处理，route.vue会在服务端客户端分别执行，因此不用再服务端客户端去分别注册。

Loading处理

因为服务端渲染的数据是在页面加载前去获取，因此在客户端路由跳转时获取数据会有一个短暂的白屏延迟，这样的体验是不好的，我们在客户端获取服务端数据的时候提供了一个loading页面去处理这个延迟，以便于告诉用户目前正在加载数据，这个loading的状态的将有pinia去控制，在项目中我们通过useCommonStore中的spining去控制它。

我们默认为你提供了一个loading页，如果你有自定义的loading页将会覆盖我们为你提供的loading，但是你还是需要useCommonStore中的spining去控制loading的状态。

UI库的处理

在做UI库的处理时，我们又遇到难题，怎样在尽可能减少用户配置的前提下优雅的去处理按需导入，因为用户可能会使用各类不一样的UI库，如antv、element等，所有按需导入的配置也不一样，你可以选择在useMain中去全局导入，但我们不推荐，因为在服务端渲染中UI库是需要被webpack处理的，因此为加入到打包，全局导入会严重拖慢服务端打包速度。

另外有种方式通过”babel-import-plugin“插件来实现按需导入，使用这种方式去处理的缺点就是需要用户去配置各自UI库的动态导入。

后面我们找到了一种比较好的方式去处理按需导入，通过unplugin-vue-component和unplugin-auto-import去处理，定义满足此插件的UI枚举（大多数高频使用的UI库都支持），通过配置ui库名字的方式去尽可能的减少配置量从而实现按需导入、自动导入。

我们定义了一个名叫“ui（AntDesignVue、ElementPlus、ElementUi、Vant、ViewUi...）”的配置变量，unplugin-vue-component支持webpack、vite等多种打包工具的支持，在webpack中通过ui去匹配对应的UI库处理插件。

至于vite中的配置由我们在跑命令的时候去动态生成，我们创建了一个vite.config.tpl模板，通过动态传入参数来生成vite配置文件，当存在该文件时将不会再生成，用户后续的配置可直接写在生成的vite.config.js文件上。

好啦，以上是我们探索的SSR解决方案，另外预告下，utopia-next即将与大家见面，敬请期待。

希望以上内容能对有需要的人有所帮助

欢迎大家一起探讨交流