关于前后端同构，我的一点思路和心得（vue、nodejs、react、模版）

最近1年多，前后端同构慢慢变成一个流行词，也许很多人还停留在前后端分离的最佳实践道路上，但实际上又有一批人已经从简单的服务端渲染走向探索最佳前后端同构方案的路上了。不过，我只是膜拜后者的过客。

虽然大家可以去网络搜索一下相关的概念解释，但这里我还是简单列举一下，我理解的术语。

1、前端渲染：浏览器一侧使用js，借助模版或vue、react、angular等框架做的DOM结构生成。

2、后端渲染：服务器一侧，使用php、nodejs等技术实现DOM结构生成，并在HTTP请求中返回给浏览器。

3、同构：浏览器一侧的JS、HTML和服务器一侧使用的JS、HTML使用同样的开发结构，同样的开发思路，同样的开发模式，尽可能实现代码复用。

明确一点，作为有追求的前端开发，我们不应该盲目跟风，一切需要从实际出发。

那么，首先，我们需要了解为什么会有同构这个概念出现。

• Web开发的历程是很有趣的，最初php、asp的年代，一切内容都是服务器渲染的；
• 再后来为了节省服务器资源，也更大限度利用客户端缓存，又出现了前后端分离的模式，从而有了专业的前端开发和后台开发。此时Web的特点是，js和html放到静态目录，也可以CDN扩散，并以ajax方式获取后台的数据，在前端进行DOM组装。这种开发方式沿用至今，这是一个好的工作模式，专业的人做专业的事，确实有利于工作效率提高。
• 再而，随着nodejs的流行，前端jser们又开始蠢蠢欲动，尝试吞并web接入这个后台的前沿地盘，把后台推到更后。大概2014年后，又出现了很多nodejs直出的方案，把页面数据都一次在HTML的请求中返回，无需浏览器端再发起ajax获取数据，而且服务器端把DOM结构都渲染好，浏览器按trunk直接做图形渲染即可。不得不说，这个方案带来了很多好处：首屏速度更快，浏览器更省电。当然，随之而来的，就是更复杂的工作模式，jser需要做服务器端的逻辑，甚至一些代码需要同时用在浏览器和nodejs上。
• 针对前边的问题，同构的探讨就开始了。。。

百度搜一下前后端同构，清一色的vue、react。这些确实是同构，但我认为范围太窄，同构不是框架带来的问题，而是因为前后端独立渲染这种架构层面带来的问题。

当然，那些同构探讨也是非常有价值的，但不在本文的讨论范围内，在这里我更想表达一下，如何从实际项目需求的角度来看，找出自己所需的同构之道。

毕竟，要知道，同构不是为了跟风耍酷，也不是为了跳槽面试的时候博点好感。同构，是为了提高用户体验的同时，提高团队的工作效率。

接下来，我想根据项目的类型，说说自己的看法。

第一种，单页面应用。

这个网站很类似一个APP，确实很有必要做成单页应用，有助于提高用户体验。

如果第一步选择了单页面应用，这里就衍生了另外的问题——SEO。而react等框架做了服务器渲染，最大目的其实也是解决SEO。

既然浏览器端选择了某个框架，例如React，而同时又考虑nodejs直出提高首屏的速度，那么就没有讨价还价的余地了，当然上react全家桶，前后端都用react。

这一种情况，也就是网上搜索到的各种文章的情况。

第二种，多页面纯数据展示，每一页都比较简单，没有分屏的必要。

如果项目是这样的情况，使用nodejs直出，无非就是提高打开速度。而前后端基本八竿子打不着，最多就是一些工具函数（转换一下日期格式，输入框校验）要做复用。

此时，没必要大费周折去考虑什么框架，因地制宜，想想自己需要什么即可。

要解决函数库的前后端复用，可以简单做commonjs/window的兼容。

如果浏览器端的代码比较多，就可以考虑粒度化，使用webpack做浏览器端代码打包，同时commonjs的写法也可以复用到nodejs层。

第三种，多页面而且每一页不是那么简单，首屏和次屏有一些HTML片段（模版）需要复用

之前我所在项目组也遇到这样的情况，怎么处理，一时之间为了赶进度也没太多考虑，使用了一些旁门左道，不好理解不好维护的方式，基于art-template做了一套有点奇怪的代码，基本没有同构一说。唯一同构的就是art-template支持浏览器和nodejs。

情况怎么恶心呢？大概是这样：

• html模版，为了复用，拆开为多个小文件，如果前后端都用到，则一方面把这个模版内容不转义不编译地塞到最终HTML中，而另一方面利用这个模版做nodejs渲染。前端ajax加载数据后渲染次屏时，再读取HTML中某个模版做处理。
• 对于处理数据的js，可封装部分，则利用跟刚才第二种情况类似的方式，做了commonjs/window的方式；不好封装的部分，基本等于写了两份。
• 前端的js，动态塞到http返回中输出的HTML中，可能有若干个js。

回头想想，当时情况确实很糟，其实可以利用已有的工具做得更优。

art-template是个好东西，这个没必要去除。刚说的前两点，表明这个项目有强烈的前后端代码复用的必要，很有需要使用更全面的同构方案。

现在我觉得有更好的方式：

• 用webpack做前端打包，这样前端各种代码和后台代码都是commonjs风格，可以二合一。而且发布前打包为一个大js文件，也省去nodejs每次请求动态合并js的消耗。
• html模版发布前先做预编译，从html+模版语法，转为纯js代码，随着webpack打包到浏览器端大js文件中。
• 后端和前端都用到的代码，基于commonjs，尽可能的抽离封装。
• 最终合并的浏览器端大js还是动态合并到首屏HTML中。

引入了webpack到浏览器端，就能很好的解决了原先html模版传播的尴尬。而模块风格的统一，也有利于前后端代码更好的复用。

至于最终浏览器js是否打包到首屏HTML中，还是单独的部署CDN，这个其实就不是同构的问题了。不过对于移动端而言，还是建议合并在一起。

抽象一下，对于第三种项目情况，跳出我原先的项目。我认为，关键是要把前后端使用的模版统一为一个方式引入。

第四种，还是多页面，浏览器端没有模版拼装的需求，第三种情况的变种。

或者说，这个不是一个单独的项目情况，只是因为用的技术方案不同。跟第三种情况一样，但次屏的渲染，我们不在浏览器端执行，而是继续交给nodejs。浏览器端通过ajax把次屏html片段拉取回来，然后直接塞到body中。而且，除此之外，浏览器端没有用户交互会导致已有的DOM发生重绘，或者极少内容重绘，不需要动用到模版。

在这个情况下，浏览器端js更纯粹的只关注事件处理。

我觉得这个又回到了第二种情况，只需要简单把一些库函数封装一下，做成前后端共用即可。

第四种情况，因为彻底抛弃了浏览器渲染，整个情况就简单多了，不需要考虑模版和很多逻辑js的前后端复用问题。