你清楚在早期的软件项目开发过程之中, 前端页面和后端业务逻辑代码其实是混合在一起, 并没有进行分离操作的吗? 那么紧接着后来业界又是因为什么样的原因促使二者走上了解绑的道路? 这种前后端分离的技术架构实施以后, 究竟为开发团队和用户带来了哪些看得见摸得着的优势与益处?
在以前写过的那篇文章当中, 产品经理这个人已经把前端和后端各自负责哪些活儿这件事给弄明白了。可就在了解情况的这个过程中, 有个写代码的程序员哥哥不假思索地冒出来了一句说: “如今这个局面全都是前后端分得清清楚楚的。
”这话让产品经理小汪整个人都犯迷糊了, 他心里头就琢磨开了, 难道说以前的时候前后端就不分开吗? 为了把这个问题搞个水落石出哎, 小汪就接着往下深挖去研究了。
不温馨的一家人
在差不多十几年以前的那个时间段里, 前端的行业地位相较于后端而言, 实际上是并没有表现得那么强势和突出的, 下面提到的这一个案例就是一种属于经典范畴内的编程框架形式。
MVC这个缩写, 对应的内容就是模型、视图和控制器, 它代表了一种被称为“模型”的部件以及一种被称为“视图”的部分, 同时也包含了控制器的部分, 这是一种软件设计的典型范例, 其核心方法在于把业务的逻辑处理、数据的管理以及界面的显示效果给彻底分开, 以此来组织代码的结构。
有趣的现象发生了, 传递的内容是发给用户使用的, 可是前端并没有直接去接触那个用户, 前端仅仅是给出来了一份样式的模板, 然后让后端那边把内容嵌进去, 再由后端这一方直接传送给用户。
在这个期间, 前端的开发人员需要进行各种操作以迎合后端开发者的意愿, 并且如果前端代码出现了错误, 还得请求后端开发者共同参与排查和解决, 这是因为前端的内容是插入到后端的模板之中所导致的问题产生的, 所以后端人员需要对由此引发的一切状况承担全部的责任与义务。
在这个时候, 前端和后端是紧紧绑定在一起的, 它们之间有着非常高度的关联, 从编程所使用的环境方面来说, 以及到了开发并进行调试环节的时候而言, 都必须要把两者放在一个共同存在的状态里面才可以进行, 这种情况对于一些只从事前端工作的人员来讲, 其实他们自己拥有的自主权利并不是很高, 而对于那些负责后端工作的人来说呢, 也必须要掌握并且了解一部分有关前端方面的专业知识内容。
于是, 前端的程序员对后端的程序员讲, 要是您只需要专注于处理业务逻辑以及数据, 然后将最终的结果交付给我, 就由我全权负责把这些信息组合起来并展示给使用者看, 这样的话大家都会觉得轻松一点吧。这样一来, 前端与后端就实现了分离。
当初是你要分开，分开就分开
前后端分离能够带来一系列的好处。
（1）编程更轻松
在前端和后端完成分离工作之后, 后端的任务变得更为纯粹, 它把核心精力全都放在了实现业务逻辑上面, 最后形成了一套规范的API接口服务, 打个比方来说, 如果系统需要进行商品的创建操作, 前段程序就会把准备好的商品详细数据发送给后端用于创建商品的专用接口, 紧接着后台系统就会负责执行具体的创建流程, 并且最终把创建操作的结果反馈回去, 再比如万一前端发送过来的创建商品信息里面缺失了必须填写的标题字段或者是价格数值, 后台程序依然有能力正常回应, 它会传回一个表示创建失败的具体状态, 并且明确指出当前信息里到底缺少了哪项内容以便进行提示等等。
在前端这里, 除了管界面样式和交互动作之外, 还把拿数据和显示数据的权力握在手心了, 这样一来, 前端程序员干事情就方便灵活多了, 要是碰上了错, 也完全可以很利索地找出是哪头的问题, 是前端的还是后台服务器的。
（2）更高的可复用性
前后端分离的情况, 在更深的层面上, 是顺应了互联网发展走向多样化的这种潮流的体现。在后端通过提供一些接口的情况下, 这些接口是可以实现不同种业务功能的内容的, 在这样的前提下, 就能够使得存在有各种类型的前端方面的东西, 甚至还包括那些外部系统的存在, 过来进行对接这个动作的发生。
这样, 公司就方便去不断地把自己的产品往外面推广开来, 具体来说就是, 今天可能推出手机网页版的产品, 明天可能推出APP版本的产品, 后天可能推出小程序版本的产品, 像这样的操作是可以一直进行的。
而对于后端开发人员而言, 他们只需要提供一次接口服务, 就不需要每新增一类客户端类型的时候, 还要重新来过进行代码编写这项工作。
以下是用户在访问网站的时候, 所涉及到的那些知识小常识。
浏览器先下载HTML的内容, 然后, 会根据HTML里的内容, 去下载并加载对应的CSS, 让网页变得漂亮起来, 接着, 也会根据HTML里的内容, 去下载并加载对应的代码, 好让这些网站具备交互动效, 在这当中, 有一部分代码会负责向服务器上的后端请求数据, 最后把这些数据显示在页面上。
然而经过一段时间过去, 前后端分离这个做法在网页上面也碰到了某些问题, 其中最为清楚展现的就是下面提到的这两点:
用户发出的请求是在浏览器的内部进行处理的。当某个网站需要展示的数量非常多的内容时, 就必须向多个后台的接口发出请求去获取数据。接着, 在用户的浏览器端完成页面的组装工作。
在这个过程之中, 就会给用户的设备的网速、以及设备的运行速度（也就是CPU、内存等方面）带来一定的压力。像百度、搜狗、谷歌这样的搜索引擎, 如果想要爬取网页的内容的话, 是需要用到爬虫工具来完成这个动作的。
爬虫是会去抓取那些在网页的HTML里面的内容的, 然后就会让其他网友可以搜索到你的网页的, 但是在这个时候HTML文件它个框架而已, 它是需要依靠什么东西才能获取到数据的, 这就非常容易导致你的网页难以被搜索引擎收录到的, 用户很有可能就搜不到你的网页了。
这给用户的设备带来的问题, 是可以通过更换一台新款手机或者更换一台新款电脑来加以避免的。然而, 搜索引擎却无法爬取到网页里面的数据内容。对于一些非常依赖搜索引擎所带来流量的产品类型来说, 这种情况所造成的破坏性影响是十分巨大的。
比如, 假若你需要获取一个菜谱, 有可能去百度搜索“芥蓝怎么炒好吃”, 然后, 从百度搜索返回的结果页面中, 访问多个美食类网站。
又比如, 假若你想去哪里游玩, 就会在百度输入“土耳其旅游攻略”来进行查询。对于那种高度依赖搜索引擎带来流量的网站而言, 如果爬虫程序无法抓取到自己的数据内容, 那么客流方面的损失, 就会显得比较严重。
运行在后面的前端
针对上诉的问题, 聪明的网页前端程序猿就想到了一个全新的办法, 那我们就先把后台的数据和HTML的内容好好整合在一起, 然后再把结果呈现给用户, 多亏了Node.JS这种能让网页前端人员使用他们熟悉的编程语言进行操作的工具, 这样一来, 前后端分离的2.0版本就这样诞生了。
那位在前端写代码的程序员跑去跟服务器里面的后端程序说, 请挪个位置, 给我留点空间, 随后他便把Node.JS这个软件放到了服务器的上面。
接着等用户或者是搜索引擎里的那个爬虫需要去访问网页的时候, 那个正在服务器上跑着的程序, 就会先去找后端要把需要的数据拿过来, 然后把这些数据拼进HTML文件里面, 最后再把弄好的结果发回给用户那边。
这样一来, 用户的设备就减少了那种需要多次向后台请求的麻烦事儿, 并且也让整体运行的速度变得更加快了, 与此同时, 那些爬虫工具也能够把那些已经把内容都填得满满当当的HTML格式网页全都给抓取下来。
读到此处, 小汪心生疑虑, 如此操作, 虽然用户体验以及爬虫相关的难题均已得到妥善解决, 然而致使那些原本应在用户浏览器端完成的事务, 全部转移至服务器端进行处理, 倘若迎来高并发访问场景, 咱们服务器的负载必将显著激增, 承受巨大压力。
前端的开发人员笑了笑, 说了句并不是这么回事。大家仔细去想一下, 其实好多用户都是在访问同一个网页的。比如说是看同一个商品, 或者是读那同一篇文章也一样的。这些个访问的请求要是让服务器在前端这儿只去请求一次后台数据的话。
然后再把这些整理好的HTML页面给保存住。那么以后再有其他人过来的时候, 就直接把这个已经生成好的HTML内容给展示给用户看就好。这样一来服务器的负担自然就轻轻松松的, 而用户那边访问的速度也会更快一些的。
小汪又提出疑问说, 如果说页面的数量变多了, 那是不是就意味着每个页面都需要去单独保存一份HTML文件, 这样一来服务器上面用来储存数据的空间不就只会变得越来越少了吗。
前端程序员哥哥接着回答说, 时间一长之后, 服务器上面堆积的HTML文件数量会变得越来越庞大, 于是就把那些长时间以来都没有人去访问的旧HTML文档给删除掉, 从而为其他刚刚保存好的新HTML文件腾出空间, 凭借所谓的“缓存”手段, 让服务器始终保持活跃的状态。
小汪恍然大悟, 原来这就是缓存啊！这下子, 小汪终于明白了前后端分离是什么回事, 以及为什么要前后端分离。
眼下, 好多大型产品都搞成了独立运转的大块头。这一来, 新的“信息孤岛”现象就出来了。拿微信来说吧, 它里面有公众号, 有小程序, 有朋友圈, 还有各种圈子。
这些玩意儿都在里头自己循环, 自己给自己供血。最后还搞了个“搜一搜”, 想把这些都统一管起来。这么一搞, 它就再也不用靠那些老派的搜索引擎来给它拉人气、带流量了。
再比如像淘宝这样的平台, 在很久以前就拒绝允许百度的网络爬虫去抓取自己平台上的商品数据内容, 而是把搜索权限严格限制在淘宝应用内部。
所以在百度搜索框里你是查不到任何淘宝商品的, 在微信生态里面你也无法找到关于淘宝的任何信息, 也无法成功访问指向淘宝的任何超链接, 要是想完成购物行为, 用户就必须直接访问淘宝官网页面或者直接下载安装淘宝的移动应用程序, 这种全新的互联网整体格局的逐渐形成, 毫无疑问将会对前端技术与后端服务体系之间的相互影响关系产生更加深远的改变作用。
