关于前端分享，我想不出什么好的话题，所以就想到了最近想做的一件事，就想出了这个标题。 也许这是一个好话题，也许这不是一个好话题。 但至少我可以分享一下我的经历：
在开始之前，我希望即使你需要后台渲染，也应该将前后端分开！ 后端提供API数据，前端使用自己的后端来渲染页面。 听起来有点绕。 简单来说，不要把很多业务逻辑放在前台，只把显示逻辑放在前台。 这样，即使有一天我们换了一个新的前端，比如移动应用程序，我们的后端仍然可用。 。
为什么需要前后端分离？
这是一个非常古老的话题。 对于大公司来说，部门太大了，需要拆分。 所以在开始之前，我们先提一下“康威定律”：
其中哪些是其中的哪些。
用中文来说，就是：设计系统的组织，它产生的设计和架构就相当于组织之间的沟通结构。上图
这张图可以说明软件开发过程中相当多的问题，我们知道软件开发中最主要的问题就是沟通。 组织结构影响我们的沟通结构，进而影响我们软件系统的结构。 好吧，我承认这可能有点偏离主题。 但是，我想说的是，组织架构可能不允许我们做出一些好的系统架构。
正如我们在《前端：前端进化史》中提到的：我们已经有了一个桌面网页，然后我们构建了一个APP。 但总有一些客户想在手机上浏览，但又不想下载APP，所以我们需要一个手机版本。 为什么会发生这种情况？ 因为用户已经养成了这个习惯，所以大部分网站都会提到桌面版、移动版、APP。 对于大多数商业公司来说，维护这三个不同系统的成本太高了。
因此，大多数企业的解决方案是后端+大前端（桌面前端、移动Web、移动APP）。 为了解决这个问题，出现了不同的解决方案——Ionic（基于.js的混合应用程序框架）和React。 但目前来说，我对 React 的共享 UI 仍然持观望态度。 有些人可能会提到Vue和Weex，但我认为它们并不是那么好用。 或许是因为接触React比较早，感觉Vue的语法不一样。
这样的话，我们只需要几个后端开发人员和几个前端开发人员就可以完成系统设计。 这种前端开发人员是近年来人们“最想要”的。
前后端渲染同一个模板
我接触的第一个SPA应用是一个基于MVC和MVC的移动网站，但它比一般的SPA更复杂——由于SEO，需要支持后台渲染。
当搜索引擎通过URL访问我们的网站时，我们需要返回相应的HTML。 这意味着我们需要在后台有相应的模板引擎来支持，而由于SPA的性质，这就需要使用纯前端的模板引擎。 因此，我们不能使用两个模板引擎来做到这一点。 维护两套模板必然是一件痛苦的事情，而且当时还没有像React这样的模板引擎。 然而，我们后来发现维护两种不同的渲染方法也是一件痛苦的事情。 因此，我们将拥有类似于以下的架构：
我们在后台使用MVC作为基础设施和模板引擎，这和使用JSP作为模板引擎没有太大区别——我们得到对应的Model，然后渲染给用户。 大多数时候搜索引擎都是基于 进行索引的，因此我们的后端可以轻松处理这些请求。 同样，当用户访问相应页面时，返回相同的页面内容。 当页面渲染完成后，就剩下处理相应的逻辑了。 换句话说，从此时起它就变成了单页面应用程序。
尽管这是一个三年前开始的项目，但这种方法在今天仍然很有趣：大多数单页应用程序只有一个主页，并由 HTTP 服务器（例如 Nginx）提供服务，而 Web 框架（例如 Koa）则提供服务。对路由进行一些处理，以允许用户通过特定的 URL 访问特定的页面。 并且我们需要保证所有用户访问的是真实的页面。 由于尚未加载，用户还可以看到完整的页面。
在这个项目中，最大的挑战是如何保证后台渲染和前台渲染的业务逻辑相同。 例如，当我们想要针对不同的产品显示不同的内容时，我们需要为其分配一些逻辑，在Java中我们也需要有相同的逻辑。 与在同一代码中拥有桌面版和移动版相比，逻辑往往更加复杂——因为在这种情况下，我们只需要维护两个不同的模板。 对于 SPA，我们必须维护两套逻辑。 后来这个框架被React和下面的响应式设计重写了。
今天你仍然可以用这种方式渲染。 JDK 1.8 附带了一个嵌入式引擎，完全支持 5.1 规范和一些扩展。
方式
当我们重新设计系统时，我们考虑了类似的事情。 将我们所有的页面渲染成静态HTML，然后使用爬虫爬取我们所有的页面，然后上传到AWS。 当时我们参考了其他组的做法，其中一个组就采用了这种方法——在本地运行一个，渲染页面，然后保存为对应的HTML。
它意味着预渲染 HTML 并将特定的 HTML 返回给爬虫。 （PS：但是，作为一个非常有经验的SEO开发人员，我根本不喜欢这种方式。要知道，有时候是模拟真实用户，不带爬虫的参数和flag来访问页面的。如果你返回的两个页面相差太大——也许你忘记更新频率，那么你可能会被认为作弊）。
对于普通用户来说，不会返回后台渲染的结果：
与上面第一种情况相比，这种方式可以大大减轻服务器的负担，可以直接交给CDN。 这时候我们只需要考虑渲染哪些页面即可。 对于数据量较小的网站来说这是一个很好的方法，但如果数据量较多，情况就会有所不同。
对于我们来说，有两个问题：一是速度问题。 他们有几万条数据，生成需要将近一天左右的时间（渲染时间长），而我们有几百万条数据。 二是数据的实时问题。 我们的产品数据每天都会更新。
反应
对于使用React的开发者来说，处理后台渲染更加容易。 毕竟React提供了一个方法叫做()。 我们要做的就是使用 或 Koa 来处理路由，然后返回相应的内容：
那么剩下的就可以通过React来解决了，就这么简单。
因为我们这个时候是前后台都使用的，所以这里可以直接实现对数据库的操作，就会出现我们一开始提到的前后台分离的问题。 这是不合理的，后台应该只返回我们需要的数据，并且可以随时更换为其他语言。