再谈前后端分离与不分离的技术利弊

由于工作的原因最近和服务端渲染（SSR）接触的比较多，这里并不只是单纯的使用某个SSR框架进行业务开发，所以为了更好的利用这项技术，我调研了市面上几乎所有常用的，有些名气的SSR框架的特点，同时呢，公司内也有位老java程序员，受他的影响我对于前后端不分离的技术也有了一定程度的了解和认知

于是我就开始思考，所谓的服务端渲染其实本质上来说就是前端不分离那一套，抛开那些上层的差异来谈，这些应用的做的最本质的事情就是：

在用户的页面响应完成后，能够立即返回带有内容以及数据的页面

就以当下前端的 SSR 技术的特点和实现过程来说，反而把这一过程变得复杂了不少

拿 remixjs 对于数据处理的方式来举例子，官方推荐所有的接口请求都尽量放到服务端来请求，然后通过 loader 动态注入到页面，然后在组件即可直接通过hook等来直接取值来消费应用数据

以前端的角度来看，因为请求放在了服务端，同时也做了SSR，所以 SEO和页面初始化的用户体验确实是上了个档次，但换来的是服务端的麻烦性。因为前端只是消费数据的一方，数据也不会凭空出现，让前端去查库也不合适，所以这种做法实际上是把一部分前端的工作内容提前到了，服务端接收页面请求那一刻开始

所以，虽然确实优化了用户体验，但是复杂度却一点都没少，因人而异可能复杂度还增加了一些，因为需要多学一个框架的语法和使用，以及少许 node 方面的知识

以上是前端的 SSR 比较有代表性的一个例子，接着我们来看看，假如换做是不分离的情况是什么样的

如果是不分离的情况，后端可以开个静态资源服务，对于 java 来说，分离时提供的是接口，不分离就是直接提供数据给模板去注入和渲染，也就是 controller 层提供的逻辑变化了而已

得利于不分离的特点，数据和视图层的结合会变得更加容易和紧密，像是前端对于资源的处理和数据的处理，都会有响应程度的简化甚至是省略，整体来说不分离的性能和复杂度反而降低了许多

目前的结论：但就对于数据和资源的处理上来说，不分离是要比前端SSR要强，甚至是强许多的，同时这也是卡前端脖子的点（性能）

说完了优势再来聊聊缺点和弱势，不然这么好的东西也不至于被时代所淘汰了

不分离最致命的点莫过于，前后端的工作重合了，前端排完了页面但是没数据，就没法继续写了。而后端给页面绑定完数据但是发现样式崩了还得喊前端来改，这样的工作的效率是及其低下的，所以前后分离才会被真正的大力提倡，并且分开后，前端有多了更多的自由和自主控制权，待形成圈子和生态后，还可以自主发展更多的特性，在不被后端牵制的情况下去做更多复杂的页面效果和处理逻辑

到这里好像已经有结论了，以技术层面来看分离和不分离都有各自的好，以项目和工作层面来看，只要是上了些规模肯定是分离强于不分离

但是这里我又有了一个新的想法，因为后端能够轻松解决当下卡前端脖子的事情（SPA初始性能不足，SEO等），所以能不能在兼顾前端自主的情况来，来绕开工作重合这个致命伤呢

就比如说，有没有可能让前端学会一些后端方面的东西，只需要懂得怎么自己绑定数据以及基本的文件操作即可，这样做相当于把接口调用的行为换成了，如何使用后端的语法来给页面注入数据而已，代价可能并没有想想中那么大

假如行得通的话，前端就依然可以继续保持自由灵活，自主发展生态圈，同时还能解决初始化的性能问题了

可能你会有这样的疑问，并不是所有的后端都是 java，比如 c# python 等都是有可能的，我不能说做个前端把每个后端语言的特性都浅尝辄耻的学一遍吧

确实是不现实，所以这里最好的办法应该是约定俗成一套业界规范，亦或者是出个中间对接层，只要符合了这些要求，那么不光是前端学起来轻松，可能一些类库都能变得跨语言互相调用了

新的结论：不分离是有希望在保持现有双方优势的情况下，还能绕开工作重合的限制，保证性能的同时各玩各的

感觉这个结论所幻想的现实已经算是比较理想的了，假如这个结论真的成立，那么不分离的技术至少在我看来确实是要优于前端的服务端技术的

还有一点得提下，对于前端来说的 SSR，其实并不能算单纯的 SSR，它有个词叫 BFF，专门为前端服务的服务端，SSR只是其中所包含的一部分，有人可能会拿这点来抨击以上的观点，但是我想强强调下，这其实不冲突，无非是细节更换了而已

我的阐述绝大部分都是站在后端的不分离的角度来思考问题的，因为我作为一名前端开发还总是站在自己的立场上说话就没法去讨论了，在非常理想的情况下，我从后端出发给可能遇到的问题都给予了一个解决方案，并且在尽量不干涉现有前端生态组织的情况下，去让不分离变得合理化，变成可行的，可最终思考下来发现还得反转

实际上现实可能并非如此，因为前后相交的那块是最大的不稳定因素

靠业界约定俗成即意味着大体相同可细节却截然不同的情况，这玩意就没法搞了

在后端和前端搞中间层和现在用 nodejs 来做没有什么区别，这条路没有什么意义

让两个不同道路上的东西，却想要它们如同同个事物那样工作本身就是有问题的，再加上前端的生态已经建立，技术也已经成熟，即便存在某些站在非前端立场上觉得不合适，甚至是不理解的情况，但从长远、全局、可持续发展的角度来看待问题，当前前端技术，可能不是最完美的，但确无疑是最合适的

这就是我建立在对于双方技术的认知上，以对方的情况为出发点，从开始觉得认同，再到自我驳倒的思考过程，如果有不同的观点欢迎给我邮箱留言