前后端分离 vs. 一体化

前言：那段“一把梭”的岁月

我犹然清楚地记起才初入行业那个时候, 运用PHP去造就页面的时日。控制器自数据库之中去检索数据, 循环开启, 径直于HTML模板里echo变量。前端逻辑是什么情况? 操弄一回DOM便视作完结事情。那个阶段, 不存在“前端工程师”与“后端工程师”清晰的区分, 我们皆称作“Web开发”。

这样一种模式, 其前后端逻辑处于“胶着”状态, 该模式便是最为原始的一体化架构。

在那之后, 伴随AJAX这东西开始兴起, 尤其是类似Vue、React这类现代跟前的前端框架突然爆发, 前后端分离就变成了业界里的主流以及那样的所谓“政治正确”, 而后、后端仅是单纯地提供以一些JSON构成的专门来用以处理的数据接口, 也就是被叫做\( API\)的那个范畴, 前端这个部分呢, 它是一个各方面通通独立的单页应用, 也就是被叫做\( SPA\)的那种, 大家相互间各自做好自己所属那一职能的事情之后, 整个世界看起来好像就是变得安静了下来, 是这种情况。

然而技术向来是在呈螺旋状态势里实现上升的。在最近几年期间, 以Next.js（React作为代表）、Nuxt.js（Vue作为代表）的Node.js全栈框架以一种意想不到的方式迅速崛起, 它们再度把前端渲染与服务端逻辑紧密地结合在了一起, 从而掀起了一股“新一体化”的浪潮。

身为一名对两种模式均进行过深度实践的开发者, 我打算聊一聊, 关于这两种架构范式, 究竟各自在哪些方面具备优势, 又在哪些地方存在不足。

模式一：前后端分离（The Great ）

这是目前大型、复杂Web应用的首选模式。

优势 (The Gains):

将专业进行分工, 使得权责清晰明确, 这乃是分离模式最为突出的好处。前端团队能够专心致力于用户体验、页面交互以及性能优化方面, 无需去操心数据库以及服务器部署之事。而后端团队则能够把精力着重放在业务逻辑、数据处理、应对高并发情况以及系统安全上面。如此一来, 这两拨人便能够将自身专业优势发挥到最大化的程度。

技术栈具备灵活性, 呈现各自为战的态势: 前端能够采用最为新潮的框架, 而后端能够运用性能最为强劲的语言。只要双方就 API 接口文档达成约定（例如/）, 彼此之间的技术选型便完全实现解耦。后端打算从 PHP 重构成 Go? 只要接口保持不变, 前端就能够毫无察觉。

推进并行开发, 能够实现效率提升: 一旦将如同“君子协定”般 的API文档确定下来, 那么前端与后端便能够如同两条彼此独立的生产线那样, 同时展开工作, 相互之间不需要等待。前端甚至能够借助Mock数据独自开展开发以及进行测试工作, 这点极大程度上致使项目周期得以缩短。

这是分离模式的, 一套 API 多端复用的杀手级优势, 后端写好的一套 API, 不仅仅能够供 Web 端来使用。甚至还能够无缝对接至 iOS App、安卓 App、小程序, 甚至是, 将其提供给第三方的开放平台, 这种复用能力, 在多端并行的的业务场景下, 价值巨大。

劣势 (The ):

沟通成本急剧增加, API文档成为了前后端之间唯独的桥梁, 然而它也时常是引发“战争”的导火索, 字段命名、数据结构、错误码定义等, 任何一处模糊不明都有可能致使联调时出现“扯皮”现象, 沟通成本远远高于一体化模式。

开发的复杂度翻了倍, 出现了翻倍的情况, 原本只是单一的一个项目, 如今却发生了变化, 演变成各自独立的两个项目, 其中包含前端所属部分的项目以及后端所属部分的项目。你必须对两套代码仓库进行维护, 要维护两套用以搭建的构建流程且需维护两套用于发布的部署流水线。系统的复杂度确实因这样着实是实实在在地增加了。

将传统的 SPA 应用返回给浏览器的, 只是一个空的 HTML 壳子以及一堆 JS, 这有着天然劣势。对于需要流量的网站, 像电商、资讯类网站而言, 搜索引擎爬虫很难抓取到有效内容, 这是致命的。尽管可以借助 SSR 等技术来补偿, 然而这又进一步加大了前端的架构复杂度。

模式二：一体化架构 (All in One)

在这里, 存在着两种形态, 一种是以PHP/JSP作为代表的“传统一体化”, 另一种是以Next.js/Nuxt.js作为代表的“现代一体化”。它们的核心思想是一致的, 其核心思想为, 由服务器直接去渲染出包含内容的HTML页面。

优势 (The Gains):

可以快速完成功能开发以及验证, 从那数据库直至页面渲染, 一个全栈工程师, 一种语言（像Node.js 全栈这样）；在这儿存在着一个代码库, 开发效率极其高, 上手速度非常快, 特别针对中小型的项目以及初创团队而言, 一体化架构简直就是“神器”, 不存在跨团队的沟通阻碍, 效率超高。

搜索引擎优化友好, 性能十分优异, 鉴于页面是在服务器一端就已经完成渲染, 浏览器以及爬虫所获取到的是完整无误的超文本标记语言, 搜索引擎优化效果极其良好, 与此同时, 用户能够更为迅速清晰地看到第一屏相关内容, 用户所体验感受出来的状态也更为上乘。

软件开发以及部署的流程具备简便性, 存在单一的代码库, 还有单一的部署单元, 如此这般极大程度地降低了运维的复杂程度, 在涉及到那些有着需要快速进行迭代以及验证想法需求的业务范畴当中, 这样的一种简便特性就是其具备的生命力。

劣势 (The ):

在技术栈绑定的状况下, 扩展性会受到限制: 一来, 一旦选定了某个一体化框架（像是Next.js）, 那么你的前端技术（React）以及后端技术（Node.js）就会被绑定；接着, 如果将来某一后端逻辑有极高的计算性能需求, 会发觉那很难轻松地借助Go或者Rust去替换这部分逻辑。

有多端复用难以支持的情况: 要是你的业务得去开发原生App, 那一体化架构就显得特尴尬。你还是得另外去开发一套专门供App用的API接口, 这就致使一体化所带来的“简单”优势完全没了。

存在“大泥球”风险, 随着项目规模增大, 要是没有精良的架构设计以及代码规范, 前端与后端的逻辑极易在同一个项目当中相互搅混掺杂组合成一团, 最终演变成一个难以进行维护的“巨石应用”, 简称为“大泥球”。

结论：没有最好的，只有最合适的

那么，我们到底该如何选择？

如果你的项目是……

技术选型向来都绝非是一场非此即彼的站队行为。身为一名开发者, 我们所要做的事情是, 去领会每种架构模式背后所蕴含的设计理念以及权衡因素, 接着如同一位经验老道的工匠那般, 针对眼前的相关任务, 挑选出最为适宜、最为称手的那件工具。