从历史演变一步步讲述为什么要前后端分离
ccwgpt 2024-10-24 09:22 19 浏览 0 评论
本文从历史演变一步步讲述为什么要前后端分离，以及前后端分离的优点
洪荒时代-大名鼎鼎 MVC 架构
比如当你要使用 JSP 或者 ASP，PHP 来发开一个网站就如下图所示
流程大致为：
请求被发送到服务器，Controller 开始处理请求，通过计算和数据库 CURD 最后得到很多需要视图层展示数据 发送到 View 视图层
视图层本质上就是模板引擎，通过从 Controller 拿到的处理好的数据，通过变量替换，最后得到一个用于浏览器展示的 HTML 片段，最终被发送到浏览器
那么，当时的开发方式和流程大致如下:
这种开发方式下面会有很多弊端，比如：
- 前端在开发过程中严重依赖后端，在后端没有完成的情况下，前端只能写好静态页面后就等着
- 前端必须要会使用后端的模板引擎的语法。A 公司用 JSP，B 公司用 C#，C 公司用 PHP，最终导致前端要学的语言越来越多
- 前端需要搭建后端的环境，同上一条，ABC 公司不同的语言 ，前端就要搭建不同的环境
- 模板引擎嵌套完毕，发现与预期不符合，静态页面返工完后还需要再来一次嵌套的工作
- 后端对前端是黑盒，有哪些字段，有哪些方法能用基本靠经验或者后端告知。调试难度非常大。
- 纯前端的性能优化有限，因为后端的性能足以决定前端的整个渲染性能。
可能会出现如下场景：
- 前端:”我这里没问题啊。后端，你那里正常么？”
- 后端:”我这里不正常啊。要不你过来看一下吧?”
- 前端:”一时我也看不出问题，我也没环境，怎么办？”
- 后端:”你没环境，坐我这边调吧。”
- 然后，前端就非常无奈地在那调代码了。
因为前端无法单独调试。一方面开发效率降低。另一方面，还有可能引发公司内部人员上的矛盾。
另外，让前端去尝试读懂每一种模板语言的代码，其实也是种折磨，比如：
<body>
<%
request.setCharacterEncoding(“utf-8”)
String name=request.getParameter(“username”);
out.print(name);
%>
</body>又比如：
<ul>
<li <if condition="$catlist['id'] eq $cid || $catlist['id'] eq $category['pid']">class="on"</if>> <a href="{$catlist.url}" class="v1"><span>{$catlist.title}</span></a>
<if condition="$catlist.child">
<dl class="snv-index-sub1">
<volist name="catlist['child']" id="v">
<dd <if condition="$v['id'] eq $cid || $v['id'] eq $category['pid']">class="ok"</if>> <a href="{$v.url}" <if condition="$v.child">class="v2"</if>>{$v.title}</a>
<if condition="$v.child">
<dl class="snv-index-sub2">
<volist name="v['child']" id="vv">
<dd <if condition="$vv['id'] eq $cid || $vv['id'] eq $category['pid']">class="ok"</if>> <a href="{$vv.url}" class="v3">{$vv.title}</a> </dd>
</volist>
</dl>
</if>
</dd>
</volist>
</dl>
</if>
</li>
</ul>这种方式耦合性太强。就算用了模板引擎，也不可避免地要去重新学习该模板引擎的模板语法。
改革时代-数据分离
前端负责开发页面，通过接口（Ajax）获取数据，采用 JQuery 等 DOM 操作库对页面进行数据和交互的操作，最终是由前端把页面渲染出来。
此时整体结构如下：
此时流程如下：
- 浏览器发送请求，后端 Controller 接受请求，并通过路由返回 HTML
- 浏览器加载服务器返回的 HTML，并去加载页面里的 JS 和 CSS
- JS 发送 AJAX 请求，从后端服务那里获取数据
- 接口返回 JSON 数据，页面解析 JSON 数据，并通过 JS 的操作渲染到页面里
但这仅仅是数据分离。
因为页面的路由还掌握在后端手里。前端只能在后端分配好的路由里面干活。
好处当然也有，就是后端不用再去学习任何后端代码了，专注于前端开发即可。
缺点也很明显，每个页面都要加载一遍资源。前端仍然不够独立。很多前端设计受限于后端。并且从此时开始暴露了一个问题：SEO
分离时代-前后端分离
前端范围持续扩大。Controller 层也属于前端的一部分。
在这一时期 前端：负责 View 和 Controller 层。
后端：只负责 Model 层，业务处理/数据等。
此时架构图如下：
前端完全接管了浏览器，后端只负责提供接口
好处有哪些呢：
- 前端可以自主发挥视图层的设计，包括代码复用，设计模式，算法等等
- 前端可以对整个渲染层面做最大的性能优化，不再受限于后端
- 前端可以独立自己的一套环境和工具包，不用再去学习别的语言和工具
同时，此时也诞生了很多库和框架。
模块加载工具：RequireJS，SeaJS
模板引擎：Artemplate，UnderscoreJS，tmpJS
前端框架：Backbone，Angular.js
单页应用框架：Angular，React，Vue （这个Angular 指的是 Angular2 开始的版本，和 Angular.js 不是一个东西）
同时，此时开发流程也变成了现在我们熟悉的样子
- 后端根据产品文档和 PRD 输出接口文档
- 前端根据产品文档和 PRD 以及 UI 稿开发前端页面
- 前端根据后端的接口文档开始开发交互逻辑
- 前后端联调
- 测试上线
大前端时代 Backend For Frontend
随着时代的发展，前后端分离也有一些弊端展现，比如首屏渲染缓慢，无法 SEO 等。
后端也慢慢地升级到微服务架构，并不想再关注页面的数据整合。而是只想关注服务自身。
并且由于，APP 时代的来临，后端要为了 APP 和 PC 不同的前端页面展示提供不同的数据包装。
所以前端将 BFF （Backend For Frontend）也接纳进前端的范畴
用 NodeJS 来实现 从浏览器 到 Server 的 最后一层桥梁
此时架构如下：
这样的好处有哪些呢？
1.前端来实现平台的差异化数据接口
APP，PC 界面展示逻辑如果不一样。此时界面展示逻辑由 NodeJS 层自己维护。如果产品经理中途想要改动界面什么的，可以由前端自己专职维护，后端无需操心。前后端各司其职，后端专注自己的业务逻辑开发，前端专注产品效果开发。
2.前端聚合接口来提升浏览器端的性能
后端由于微服务架构的划分，一个页面需要的数据往往要由多个接口来完成，无形增加了请求的成本。浏览器在同一个 TCP 上向同一个域名发送的请求是有限的。所以前端完全可以在 BFF 层将微服务的接口聚合，这样页面中只要请求一个接口
3.SEO友好
React，Vue，Angular 更是有同构 SSR 的技术，来解决前后端分离不能 SEO 的问题。
实际上就是首屏渲染走 NodeJS 服务器渲染。后续页面跳转仍然是单页的形式。这样既能让搜索引擎的爬虫爬到数据，又能解决首屏渲染慢的问题。还能保证单页 SPA 应用的优势，资源只用加载一份，切页面不用重新加载资源。
结语
前后端分离有很多优势，解决了很多问题，比如学习成本，沟通成本，性能优化。同时也变相的帮助后端更加简单独立的完成后端部分，如果需要 SEO，需要首屏性能，还可以通过 SSR 的技术用 NodeJS 来实现。
但是这无形中也增加了前端的学习成本。本来前端只需要掌管视图的部分。现在因为数据层，交互层，以及 BFF 都划分到前端了，前端必须对公司的业务流程有深入的了解，也要对其他方面的知识有所了解。需要不断地学习和积累。不过这种模式下后端可能会觉得，前端夺权，前端在抢活。但是时代是在进步的，需要不断地往前走。才能不断地成长和进步，谁想要被时代所抛弃呢？
加油啊，各位前后端开发者们！！！
后面会有一篇专门详细说一说，前后端分离的情况下，做SEO优化的方式方法，以及具体细节操作。方法其实有很多。
相关推荐
- 详解DNFSB2毒王的各种改动以及大概的加点框架
-
首先附上改动部分，然后逐项分析第一个，毒攻掌握技能意思是力量智力差距超过15%的话差距会被强行缩小到15%，差距不到15%则无效。举例：2000力量，1650智力，2000*0.85=1700，则智力...
- 通篇干货!纵观 PolarDB-X 并行计算框架
-
作者：玄弟七锋PolarDB-X面向HTAP的混合执行器一文详细说明了PolarDB-X执行器设计的初衷，其初衷一直是致力于为PolarDB-X注入并行计算的能力，兼顾TP和AP场景，逐渐...
- 字节新推理模型逆袭DeepSeek，200B参数战胜671B，豆包史诗级加强
-
梦晨发自凹非寺量子位|公众号QbitAI字节最新深度思考模型，在数学、代码等多项推理任务中超过DeepSeek-R1了？而且参数规模更小。同样是MoE架构，字节新模型Seed-Thinkin...
- 阿里智能化研发起飞!RTP-LLM 实现 Cursor AI 1000 token/s 推理技术揭秘
-
作者|赵骁勇阿里巴巴智能引擎事业部审校|刘侃，KittyRTP-LLM是阿里巴巴大模型预测团队开发的高性能LLM推理加速引擎。它在阿里巴巴集团内广泛应用，支撑着淘宝、天猫、高德、饿...
- 多功能高校校园小程序/校园生活娱乐社交管理小程序/校园系统源码
-
校园系统通常是为学校、学生和教职工提供便捷的数字化管理工具。综合性社交大学校园小程序源码:同城校园小程序-大学校园圈子创业分享，校园趣事，同校跑腿交友综合性论坛。小程序系统基于TP6+Uni-app...
- 婚恋交友系统nuiAPP前端解决上传视频模糊的问题
-
婚恋交友系统-打造您的专属婚恋交友平台系统基于TP6+Uni-app框架开发；客户移动端采用uni-app开发，管理后台TH6开发支持微信公众号端、微信小程序端、H5端、PC端多端账号同步，可快速打包...
- 已节省数百万GPU小时!字节再砍MoE训练成本，核心代码全开源
-
COMET团队投稿量子位|公众号QbitAI字节对MoE模型训练成本再砍一刀，成本可节省40%！刚刚，豆包大模型团队在GitHub上开源了叫做COMET的MoE优化技术。COMET已应用于字节...
- 通用电气完成XA102发动机详细设计审查 将为第六代战斗机提供动力
-
2025年2月19日，美国通用电气航空航天公司（隶属于通用电气公司）宣布，已经完成了“下一代自适应推进系统”（NGAP）计划下提供的XA102自适应变循环发动机的详细设计审查阶段。XA102是通用电气...
- tpxm-19双相钢材质（双相钢f60材质）
-
TPXM-19双相钢是一种特殊的钢材，其独特的化学成分、机械性能以及广泛的应用场景使其在各行业中占有独特的地位。以下是对TPXM-19双相钢的详细介绍。**化学成分**TPXM-19双相钢的主要化学成...
- thinkphp6里怎么给layui数据表格输送数据接口
-
layui官网已经下架了，但是产品还是可以使用。今天一个朋友问我怎么给layui数据表格发送数据接口，当然他是学前端的，后端不怎么懂，自学了tp框架问我怎么调用。其实官方文档上就有相应的数据格式，js...
- 完美可用的全媒体广告精准营销服务平台PHP源码
-
今天测试了一套php开发的企业网站展示平台，还是非常不错的，下面来给大家说一下这套系统。1、系统架构这是一套基于ThinkPHP框架开发的HTML5响应式全媒体广告精准营销服务平台PHP源码。现在基于...
- 一对一源码开发，九大方面完善基础架构
-
以往的直播大多数都是一对多进行直播社交，弊端在于不能满足到每个用户的需求，会降低软件的体验感。伴随着用户需求量的增加，一对一直播源码开始出现。一个完整的一对一直播流程即主播发起直播→观看进入房间观看→...
- Int J Biol Macromol .|交联酶聚集体在分级共价有机骨架上的固定化:用于卤代醇不对称合成的高稳定酶纳米反应器
-
大家好，今天推送的文章发表在InternationalJournalofBiologicalMacromolecules上的“Immobilizationofcross-linkeden...
- 【推荐】一款开源免费的 ChatGPT 聊天管理系统，支持PC、H5等多端
-
如果您对源码&技术感兴趣，请点赞+收藏+转发+关注，大家的支持是我分享最大的动力！！！项目介绍GPTCMS是一款开源且免费（基于GPL-3.0协议开源）的ChatGPT聊天管理系统，它基于先进的GPT...
- 高性能计算(HPC)分布式训练:训练框架、混合精度、计算图优化
-
在深度学习模型愈发庞大的今天，分布式训练、高效计算和资源优化已成为AI开发者的必修课。本文将从数据并行vs模型并行、主流训练框架（如PyTorchDDP、DeepSpeed）、混合精度训练（...
欢迎 你 发表评论:
- 一周热门
- 最近发表
-
- 详解DNFSB2毒王的各种改动以及大概的加点框架
- 通篇干货!纵观 PolarDB-X 并行计算框架
- 字节新推理模型逆袭DeepSeek，200B参数战胜671B，豆包史诗级加强
- 阿里智能化研发起飞!RTP-LLM 实现 Cursor AI 1000 token/s 推理技术揭秘
- 多功能高校校园小程序/校园生活娱乐社交管理小程序/校园系统源码
- 婚恋交友系统nuiAPP前端解决上传视频模糊的问题
- 已节省数百万GPU小时!字节再砍MoE训练成本，核心代码全开源
- 通用电气完成XA102发动机详细设计审查 将为第六代战斗机提供动力
- tpxm-19双相钢材质（双相钢f60材质）
- thinkphp6里怎么给layui数据表格输送数据接口
- 标签列表
-
- MVC框架 (46)
- spring框架 (46)
- 框架图 (58)
- bootstrap框架 (43)
- flask框架 (53)
- quartz框架 (51)
- abp框架 (47)
- jpa框架 (47)
- laravel框架 (46)
- express框架 (43)
- springmvc框架 (49)
- 分布式事务框架 (65)
- scrapy框架 (52)
- java框架spring (43)
- grpc框架 (55)
- orm框架有哪些 (43)
- ppt框架 (48)
- 内联框架 (52)
- winform框架 (46)
- gui框架 (44)
- cad怎么画框架 (58)
- ps怎么画框架 (47)
- ssm框架实现登录注册 (49)
- oracle字符串长度 (48)
- oracle提交事务 (47)