关于react同构

这样的架构设计使得前后端开发可以并行进行，职责清晰——前端工作主要集中在浏览器端

前端开发只需要完成对测试数据的模拟，环境相对容易配置，能做到本地开发，脱离后端的支持；而后端专注于业务逻辑，负责API接口的实现。

然而任何技术架构和设计都不可能脱离时代而永远存在，技术的演进一定会随着发展愈演愈烈。这种架构模式在提升开发效率的同时，短板也很明显，比如不利于SEO（Search EngineOptimization，搜索引擎优化）和存在性能问题等。

SEO是一种通过了解搜索引擎的运作规则来调整网站，以及提高目的网站在有关搜索引擎内排名的方式。如今，网民主要通过搜索引擎在网上查找信息和资源。SEO做得好，能够直接提升网站在搜索引擎搜索结果中的展现排名，更有利于页面的曝光。可是采用前后端分离的方式，由于页面的数据内容主要由JavaScript脚本动态生成，因此非常不利于搜索引擎获取该页面的信息，影响该页面的SEO。

另外，在这种架构设计下，我们会发现来自浏览器端的请求增多了，体现在用户体验上，就是用户必须等待JavaScript脚本加载完成，且真正执行时才会发起数据请求。接下来，等待数据成功返回后，脚本完成页面内容渲染，用户才可以得到最终页面。这样做直接降低了页面首屏展现的时间，特别是在移动互联网环境下，对首屏加载性能的影响很大。

什么是同构

随着Node.js的异军突起，前后端开发有了归一化编程语言的基础土壤，页面模版、第三方依赖机制等都有实现前后端统一的契机。React率先引领了这种潮流，同构的概念也因此得以更广泛的传播。

需要读者明白的是，同构应用并不是不需要浏览器端渲染内容，而是使服务端和浏览器端渲染达到一种平衡。那么，怎么理解这种平衡呢？

在服务器上生成渲染内容，让用户尽早看到有信息的页面。一个完整的应用除包括纯粹的静态内容以外，还包括各种事件响应、用户交互等。这就意味着在浏览器端一定还要执行JavaScript脚本，以完成绑定事件、处理异步交互等工作。

从性能及用户体验上来看，服务端渲染应该表达出页面最主要、最核心、最基本的信息；而浏览器端则需要针对交互完成进一步的页面渲染、事件绑定等增强功能。所谓同构，就是指前后端共用一套代码或逻辑，而在这套代码或逻辑中，理想的状况是在浏览器端进一步渲染的过程中，判断已有的DOM结构和即将渲染出的结构是否相同，若相同，则不重新渲染DOM结构，只需要进行事件绑定即可。

从这个维度上讲，同构和服务端渲染又有所区别，同构更像是服务端渲染和浏览器端渲染的交集，它弥补了服务端和浏览器端的差异，从而使得同一套代码或逻辑得以统一运行。同构的核心是“同一套代码”，这是脱离于两端角度的另一个维度。

同构的优势如下：

更好的性能。这里的性能主要指渲染更加迅速、首屏展现的时间更快、文件更少，以及文件体积更小。

SEO优化支持。服务端接收到请求后，会返回一个相对完整、包含了初始内容的HTML文档，所以更有利于搜索引擎爬虫获取信息，提高搜索结果展现排名。同时，更快的页面加载时间也有利于搜索结果展现排名的提升。

实现更加灵活。服务端渲染只是直出页面的初始内容，浏览器端仍然需要做后续工作，以完成页面的最终展现。这样服务端渲染和浏览器端渲染仍可以平衡，在很大程度上也能实现代码复用。

可维护性更强。因为借助React等类库，我们完全能够实现大范围的代码复用，避免了服务端和浏览器端同时维护两套代码或逻辑。因此，整体代码量更少，维护成本更低。

对于低端机型更加友好。因为内容的初步渲染是在服务端完成的，所以对于低端机型更加友好，不至于页面加载时出现白屏幕的状况。

对于恶劣的网络环境更加友好。传统的前后端分离方式，在所有的JavaScript脚本下载并执行完毕后，才会呈现页面内容，中间经历了较多的网络请求，在恶劣的网络环境下，无疑增加了页面呈现基本内容的难度。在这方面，同构应用显然更有优势。

更好的用户体验。为了更加合理地平衡服务端和浏览器端渲染内容，我们可以将页面重要的核心部分设计在服务端完成，而次重要的交互部分可以在更重要的内容渲染完毕后，由浏览器端渲染或实现，这将有力地提升用户体验。

同构的劣势如下：

服务端处理的逻辑增多，增加了复杂性。

服务端无法完全复用浏览器端代码。

增加了服务端的TTFB（Time To First Byte）时间。TTFB时间指的是从浏览器发起最初的网络请求，到从服务器接收到第一个字节的这段时间。它包含了TCP连接时间、发送HTTP请求的时间和获得响应消息的第一个字节的时间。因为对数据的获取和对页面初始内容的渲染，势必会降低服务端返回的速度。