再谈先后端分离

前段时间我针对手头上的项目前端配置进行了反思以及总结而且写了两篇文章: webpack传统后端渲染的项目前端配置, webpack配置以前后端不分离, 很显然这些配置能知足一时的需求, 可是也有不足. 今天继续总结, 这里应该不涉及到具体后端语言, 只对前端配置进行描述. 毕竟配置工程师(逃

静态资源管理

传统后端主导的项目中对静态资源不多处理, 毕竟后端主要仍是处理业务逻辑, 可是这样一来前端的命门就被后端抓在手里并且还不受重视, 这就致使这么一个状况: 前端写好静态页面和css js扔给后端转换为jsp之类的后端模板. 更大的问题是后端会在页面中增长不少后端逻辑. 这就弊处. 后端看在页面写一段java代码处理逻辑方便那就很天然的这样干了. 后端写完逻辑后前端发现本身看不懂了(这里就须要稍微懂一点后端了), 这里不能说谁错了, 只是开发模式很不合理. 咱们须要作的是尽可能避免这种状况的出现.

对于后端模板咱们姑且不算静态资源. 那么传统后端对静态资源的处理方式就以下图所示:

很明显, 静态资源的处理都在后端. 可是静态资源的无论呈现仍是处理都应该是前端的事情. 甚至极端状况下html文件也应该是前端的事情, 因此spa(单页应用)诞生了:

后端再也不直接参与前端逻辑和静态资源的处理, 这样固然有好处: 先后端算是彻底分离了, 页面由前端渲染, 可是弊处也至关明显: seo的问题, 首次加载速度... 等等. 再者前端没法控制后端的接口质量, 致使分工却是分了, 可是项目进度反而是慢了, 老项目也不可能进行彻底的分离, 我认为操做性很强的web应用(注意是应用)彻底能够直接spa, 好处也毋庸置疑. 可是对于一些展现性的网站, 好比知乎, 简书等却不必定非得这样(知乎的问题后面会提到, 不彻底是react).

对于上面的状况, 咱们可能有个更好的开发模式, 也是我目前在用的, 以下图所示:

看起来彷佛第二个没有明显不同. 可是咱们要知道, 对于不少列表展现类的网页可能后端渲染很方便不少, 对于单页应用来讲多入口的webpack配置多是不经常使用的. 可是若是是后端渲染的网页, 每一个模板咱们都须要提供一个接口: 就是以前我写的文章, 有兴趣能够回头看看. 后端经过读取资源表来获取静态资源, 也就是说后端基本不须要跟静态资源打交道了. 更有趣的是咱们能够在任意页面引用任意框架, 对于某个操做性很强的页面来讲, 咱们彻底可使用vue, react ng等. 或者使用某个组件.

关于seo

其实seo我也不了解, 可是姑妄说之. 咱们首先来看两个网站: 掘金和知乎, 在baidu和google下的搜索表现:

知乎在google:

掘金在google:

知乎在baidu:

掘金在baidu:

上面咱们能够看到, 两者其实仍是有点差距的吧, 固然也有多是掘金没太关注这方面.

可是经过开发者工具其实咱们能够看到两者分别用了react和vue, 那么两者差别到底在哪呢? 咱们分别禁用两个网站的js(此处无图), 掘金一片空白, 知乎至少能够正常渲染.

掘金彻底是前端渲染, 知乎作到这一点也很简单就是后端渲染一遍前端再渲染一遍(貌似是多余的), 可是我认为这是值得的, 后端不须要写接口, 把须要渲染的数据做为INITIAL_STATE 赋值给window, 知乎点赞之类的操做都是框架进行处理的.

其实蛮建议掘金也这样处理得, 掘金网页端访问并非很爽.

总结

上面不涉及具体代码以及配置, 可是思路在那里, 无论后端是什么, 咱们前端能够都写的很爽, 一样, 先后端分离不是说什么都是给前端干, 彻底能够协调工做量.

最后有问题能够加群讨论以及欢迎关注个人公众号: