再谈前后端分离

[xiadd]

再谈前后端分离

前段时间我针对手头上的项目前端配置进行了反思以及总结并且写了两篇文章: 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, 知乎点赞之类的操作都是框架进行处理的.

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

总结

上面不涉及具体代码以及配置, 但是思路在那里, 不管后端是什么, 我们前端可以都写的很爽, 同样, 前后端分离不是说什么都是给前端干, 完全可以协调工作量.

最后有问题可以加群讨论以及欢迎关注我的公众号:

[Skura23]

请问楼主现在有比较好的解决方案了么?

[xiadd]

@Skura23 上面其实已经说过了 nodejs起一个开发服务器，node服务会生成一个资源列表， 也就是maniest.json, 后端读取这个资源列表，这应该是一个比较成熟的解决方案了， 当时我们是php渲染的页面。