前后端分离的演进

发表于 更新于 分类于 本文字数： 2.4k 阅读时长 ≈ 2 分钟

有幸参与了所在项目的架构升级，初次接触到了 SSR 的概念，就越发感兴趣 我们站在巨人的肩膀上一边享受社区红利，一边躁动不安

鲁迅先生说过

技术上的问题总有技术去解决
没错 比如我现在就学会问 为什么
为什么会如此发展？为什么会有这个概念？它能解决什么问题？它从哪里来.. 又要到哪里去..emm..

事实上，任何一项技术的发展 都是由问题推动的，所以 trouble is friends！

工作时间不短不长，刚好经历了几个阶段.

第一阶段（静态页面万岁）

两年前入职的时候，就用的如此神奇的技术，当时 react、vue 等已经热火朝天了，我表示很惊讶，因为刚毕业就加入 react 大军了，当时还用的是蚂蚁金服还在 degugger 阶段的 dva, 对于当时的我来讲，这种歌神奇的技术第一次真正接触，写好页面，就扔给后端小哥哥了，还真的不习惯，比较闹心的一点是 没有 bug 还好，一旦需要调试，会跟后端小哥哥一起看，是真的浪费时间，重点是效率也贼低.

其实现在看来 ，这大概是最初的前后端分离
前端负责静态页面和交互，后端可能就要负责数据处理并返回完整的页面
一旦涉及到诸如 JSP、PHP smarty 模版的编写，就容易职责不清了.. 以至于互相甩锅！

缺点明显：

  1. 前后端分工不明，难以实现效率最大化
  2. 前端会极度依赖后端环境，数据格式的沟通成本过高
  3. 不利于前端技术的发展

第二阶段（AJAX 时代）

随着前端技术的发展，尤其是 AJAX 和 Node.js 的出现，一种前后端分离的架构模式应运而生，极大的缓解了前后端 RD 会互相撕逼的 bug，前后端分工变得清晰，以 AJAX 接口当作桥梁，各取所需（😂）

emm.. 徒手画的还不是特别准确的图来意会一下用户请求页面的过程
cache_detai

优点

  1. 分工明确，前后端各司其职，后端专注业务逻辑和功能的实现，前端专注页面设计。
  2. 接口明确，并行开发，在后端接口没有实现好之前，前端完全可以自己通过 Node.js 的的 Web 框架模拟接口

    缺点

  3. 数据请求，处理扽好复杂逻辑被移植到浏览器端，js 脚本越来越复杂
  4. 不利于 SEO（后面会解释）存在性能问题
  5. 这种模式下，用户必须等待 js 脚本加载完成，真正执行时发数据请求，等数据返回，脚本完成页面的渲染，才能看到页面，导致首屏展现时间拉长，特别是在移动互联网下，对首屏加载性能的影响很大

第三阶段（SPA）

SPA（single page application）：是一种 网络应用程序 (WebApp) 模型
在传统的网站中，不同的页面之间的切换都是直接从服务器加载一整个新的页面，而 SPA 是通过动态重写页面的部分与用户交互，从而避免了过多的数据交换，响应速度更快

目前常见的 SPA 框架

  • AngularJS
  • React
  • Vue.js

任何技术架构的升级都不可能脱离时代永远存在，技术的演进一定会随着发展愈演愈烈

优点

  1. 前后端分离的优点它都有除此之外，它页面之间的切换很快

    缺点

  2. 首屏打开速度很慢，因为用户首次加载需要先下载 SPA 框架及应用程序的代码，然后再渲染页面
  3. 不利于 SEO

为什么 SPA 不利于 SEO？
目前而言，部分搜索引擎如 Google、bing 等，它们的爬虫虽然已经支持执行 JS 甚至是通过 AJAX 获取数据了，但是对于异步数据的支持也还不足 (也可能是搜索引擎提供商觉得没必要)
SPA 应用中，通常通过 AJAX 获取数据，而这里就难以保证我们的页面能被搜索引擎正常收录到。并且有一些搜索引擎不支持执行 JS 和通过 AJAX 获取数据，那就更不用提 SEO 了

第四阶段（服务端渲染 SSR）

什么是服务端渲染？

服务端渲染会把数据请求过程放在服务端，相对于前后端分离的方式，获取数据提前，页面模版结合数据的渲染处理也会在服务端完成

优点：

  1. 当浏览器初次请求页面后，用户第一次拿到的 HTML 文档已经进行了初步的内容渲染，利于 SEO 优化 也解决了首屏的性能问题
  2. 总的请求数并没有变，只是把浏览器的一部分数据请求转移到了服务器上 事实上 服务端进行数据拉取的成本要小于浏览器端，传输更加高效，这也是性能提升的关键
  3. 更快的响应时间，不用等待所有的 JS 都下载完成，浏览器便能显示比较完整的页面了
  4. 更好的 SEO，我们可以将 SEO 的关键信息直接在后台就渲染成 HTML，而保证搜索引擎的爬虫都能爬取到关键数据

    缺点：

  5. 相对于仅仅需要提供静态文件的服务器，SSR 中使用的渲染程序自然会占用更多的 CPU 和内存资源
  6. 一些常用的浏览器 API 可能无法正常使用，比如 window、docment 和 alert 等，如果使用的话需要对运行的环境加以判断
  7. 服务器端渲染的结果与浏览器端的结果不一致

技术的历史总是惊人的相似，这里的服务端渲染和开始的 smarty 等模版渲染并没有本质上的区别，当然了这并不是倒退，实际开发项目中，依赖 react 实现的服务端渲染并不是简单的渲染内容，也可以实现前后端代码复用 -> 同构

第五阶段（SPA+ SSR 同构）

何为同构？

服务端渲染出最核心，最基本的信息，浏览器端针对交互完成进一步的渲染，事件绑定等增强功能

但是 两端渲染必定有很对冗余代码逻辑（都有 fetch 数据的过程）

同构：就是前后端共用一套代码逻辑，它就像是服务端与客户端渲染的交集，弥补了服务端和浏览器端的差异

好像很高级的样子

但是优劣也比较明显

优点

  1. 更好的性能 渲染更加迅速 首屏展现的时间更快
  2. SEO 优化支持，服务端收到请去后 会返回一个相对完整，包含 html 的文档，所以更有利于搜索引擎爬虫获取信息，同时，更快的加载时间也有利于搜索结果展现排名的提升
  3. 实现灵活，服务端渲染做客户端渲染的后续的工作，实现代码复用
  4. 可维护性更强（同一套代码逻辑维护成本低）
  5. 对于低端机型友好，因为页面内容是在服务端渲染的 不至于出现白屏
  6. 弱网有好 不会再等 js 执行完毕再去呈现页面
  7. 更好的用户体验 可以将最重要的先渲染次重要的后渲染

缺点

  1. 服务端逻辑增多
  2. 服务端无法完全复用浏览器端代码
  3. 增加了服务器的 TTFB（time to frist byte）时间

总结

合理利用 SSR 结合 SPA 实现同构应用 是我们日后重心
下一篇将动手写个同构的 demo

就这样。