概论

你或许会问，现在都是前后端分离（至少大趋势是这样的），又何苦来这么一个专题？

传统的服务端渲染（AXUM 渲染）

这其实是最传统的方法，早期的 ASP/PHP 等 Web 开发技术都是使用这种方式。好处在于：

缺点也很明显：

• 利于团队协作。专职前端工程师开发、维护前端，专职后端工程师负责开发、维护后端 API
• 维护成本显著下降。

缺点：

• 不利于SEO。最终的前端页面只是一坨 JS，数据需要通过 JS 动态从服务端获取，对SEO不友好。
• 如果没有全栈工程师，意味着需要前端岗和后端岗。
• 前端和后端需要分别部署。

利用“嵌入”技术，将前后端打包为单个 APP

在 RUST 中，是可以将前后端分离方案中，构建出来的前端页面打包到 RUST 中的，与后端一起成为单个二进制文件。本方法也同样适用于传统的模板渲染方式。

利用此方法，最终构建出来的只有一个二进制文件，非常方便部署——不需要额外复制一大堆模板、静态文件等。

React/Vue 最大的问题是 SEO。所以在前端生态圈里出现了“全栈框架”，这里的“全栈”是指客户端、服务端都由 React/Vue 实现。其中关键技术就是“水合”。

React 的代表是 Next.JS，Vue 的代表是 NuxtJs。好处在于：

• 解决了 SEO 问题
• 使用熟悉的 React/Vue 生态前后端通吃

但是，等等，我们的后端是 AXUM 呀，对于我们来说，无论原生 JS，还是 REACT/VUE，其作用域应该仅限于前端，或者说 UI。所以这种方式带来了新问题：

• 职责重叠：我们的后端是 AXUM，而这些“水合”渲染前后端都是 NodeJs，也就意味着我们除了要写 AXUM 后端，还得再写 Next.JS/NuxtJs 后端。
• 失去了 Rust 低耗、高吞吐的特点。会造成明明 AXUM 后端坚挺的运行着，但 Next.JS/NuxtJS 却因为资源占用高、吞吐低的原因挂了。由木桶原理可知，直接把整个应用的处理能力拉低。

本站目前使用的就是这个方案，而且因为 NodeJS 的短板造成前端进程崩溃而 AXUM 编写的 API 依然坚挺的情况经常发生。

后续章节，我们将对这些方案一一进行说明，并在最后章节试图寻找不同场景下的 AXUM UI 的最佳方案。