这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
一、本堂课重点内容：
- CSR
- SSR
- SSG
- SSR、SSG的优势
- 为什么需要同构
- 脱水和注水
二、详细知识点介绍：
B端应用是挂在内网上，提供给管理员使用，如学生管理系统等，C端应用则是挂在外网上，提供给整个互联网上的用户使用。
- CSR
客户端渲染，常见B端WEB应用开发方式，前后端分离，服务器压力相对更轻，渲染工作在客户端进行，服务器直接返回不加工的HTML用户在后续访问操作。资源在一次请求中就加载完成，首屏时间更长。
- SSR
服务器端渲染，代码耦合度高，且模板语言中混杂编程语言，对于一些复杂的功能，维护起来很痛苦，在这种模式下Java、PHP负责渲染的逻辑，而前端只负责UI和交互。
优化版本：同构SSR：前后端一体化，一套React代码在服务器上运行一遍，遇到浏览器又运行一遍，前端后端都要参与渲染，而且首次渲染出的HTML要一样。
BFF：是一个Node服务，对下游数据拼接汇总交给前端，是前后端的中介，后端接口只需专注于数据而不用在乎页面内容，是服务于前端应用的后端。
- SSG
静态站点生成，在构建的时候直接把结果页面输出html到磁盘，每次访问直接把html返回给客户端，相当于一个静态页面。相比SSR，因为不需要每次请求都由服务器端处理，所以可以大幅减轻服务器端的压力。
缺陷：只能用于静态页面，无法生成与用户相关的内容，比如账号、头像等，也就是所有的用户访问的页面都是相同的，属于偏展示的页面。
CDN：建立并覆盖在Internet之上，分布在不同区域的边缘节点服务器群组成的分布式网络。
- SSR、SSG的优势
利于SEO
浏览器的推广程度，取决于搜索引擎对站点检索的排名。在输入关键词后，搜索引擎会爬取指定页面的HTML，并根据用户输入的关键词对页面进行排序检索，最后形成我们看到的结果。
B端应用的html不会直接展现页面元素，而是在后续解析中添加。在用户搜索关键词时，页面中存在该元素，但在直接响应中是找不到的，这也是C端应用不使用CSR的原因。
而C端应用的重点在于信息的曝光，使用SSR，服务器会参与页面渲染，返回的内容存在关键词。用户搜索时可以在返回内容中获得该关键词，从而提高站点与关键词的相关性，提高站点在搜索结果中的排名。
更短的首屏时间
SSR和SSG只需要请求一个HTML文件就能展现出页面，虽然在服务器上会调取接口，但服务器之间的通信远比客户端快，甚至是同一台服务器的本地接口调取，因为不再需要请求大量js文件，这就使得SSR/SSG可以拥有更短的首屏时间。
轻微的首屏时间也影响用户体验，为了给用户更好的体验，在这方面的要求会更严格。
SSR demo（简易的服务器端渲染框架）：github.com/czm12904337…
- 为什么需要同构
即服务器端和客户端把同样的事都做一遍，保证客户端和服务端一致。页面的一些事件需要js进行处理，如果没有同构，服务器端没有做相同的事情，例如onclick事件就会变成空事件，导致无法触发。
src\server\index.tsx下的这一行：
其中，client_build是使用webpack打包出来的客户端js文件，而这行代码就是相当于在服务器端加入一个中间件，调用js把它引到静态模板页面中。
删除这一行后，服务器端返回的模板页面没有这个js，页面中的按钮就没有反应。即如果不进行同构，就无法保证一些事件能否得到触发。
- 脱水和注水
脱水和注水的必要性：在服务器端返回html的过程中，将其中的初始化数据脱出来变成水，即下例中展示的代码的部分，然后在客户端渲染的时候，拿出服务端在浏览器端注入的水，放入这个页面中，从而保证客户端和服务器端保持一致。
src\server\index.tsx下的这部分就属于脱水和注水的过程。
src\pages\Demo\store\demoReducer.ts下的这段代码表示：
如果有window，页面中显示的内容就是window下的demo，否则就选择默认数据。
删除第一段代码，并将第二段改为直接取默认数据后，页面显示的内容就是‘默认数据’，并报错说明服务端返回的数据和客户端用的数据不一致。
三、课后个人总结：
通过本节课程，我了解到了CSR、SSR和SSG的区别及其应用场景，以及SSR、SSG的优势，用同构保证客户端与服务端的一致性，脱水和注水的过程和意义等知识。
