前后端开发的羁绊

萌芽初露（web1.0 - MVC架构)

要向最初的程序开发，并没有前端开发工程师这个职位，页面也没有太多的交互，页面开发使用最流行就是网页三剑客：Dreamweaver，Fireworks，Flash。
很多情况下，前端职位都是兼职，有两种模式进行开发：

• UX基于设计稿直接导出html页面，交由后端套模版
• 后端直接兼职了前段时间页面的开发，基于微软的asp、.net，java的jsp进行开发

这个阶段前端页面没有太多的交互逻辑，更多的是数据展示和表单输入，每次的交互都要进行后端调用，经常要触发页面的刷新，而且没有太多的动画，只是简单的界面展示。

直到ajax技术的广泛应用，Ajax即**A**synchronous **J**avascript **A**nd **X**ML（异步JavaScript和XML）在 2005年被Jesse James Garrett提出的新术语，用来描述一种使用现有技术集合的‘新’方法，包括: HTML或 XHTML, CSS, JavaScript, DOM, XML, XSLT, 以及最重要的XMLHttpRequest 使用Ajax技术网页应用能够快速地将增量更新呈现在用户界面上，而不需要重载（刷新）整个页面，这使得程序能够更快地回应用户的操作。

紧接着改变前端开发环境的重要前端框架JQuery的出现，jQuery的核心特性可以总结为：具有独特的链式语法和短小清晰的多功能接口；具有高效灵活的CSS选择器进行扩展；拥有便捷的插件扩展机制和丰富的插件。同时jQuery兼容各种主流浏览器。

同时浏览器厂商也开始逐渐统一标准和协议，为前端职业的产生奠定技术基础，也慢慢的有专职做前端人员出现，可以说工作年限超过10年的前端开发基本都有后端的开发经验。

茁壮成长（web2.0 -MVVM架构）

前端MVVM架构的出现促进了前端开发与后端业务逻辑的分离，真正实现“分家”：分工协助、各司其职、拒绝捆绑。
由此诞生了前段的三大框架：Angular、VUE、React

由于智能手机的产业的爆发，最终的OS胜利者是iOS和android，这2个操作系统的safari、chrome的浏览器架构webkit浏览器框架也是基于Webkit，虽然略有不同，但是相比起IE的格格不入，对于前端开发者来说已经好的太多了，现在IE已经抛弃了老的架构，开始拥抱webkit了。
同时Google发布了V8引擎，Html5、CSS3的接连登场，给了前端更大的发挥空间，招聘网站上才真正出现了前端开发工程师这个职业。
此时，前端和后端作为职业就行了区分，开发工具、部署方式、调试工具…都进行了拆分，两者之间唯一的“沟通桥梁”：API ，再通过ajax调用实现前后端之间的协作沟通。两者也解耦了

• API消费者（前端）：通过接口文档了解接口信息，聚焦点：接受数据、处理数据、处理渲染逻辑
• API生产者（后端）：提供接口以及接口文档 聚焦点：提供数据、提供API文档
  开发流程也开始转变：

• 后端编写和维护接口文档，在 API 变化时更新接口文档
• 后端根据接口文档进行接口开发
• 前端根据接口文档进行开发 + Mock平台
• 开发完成后联调和提交测试

从上面的开发流程我们可以看出，分家之后，接口文档是最关键的沟通桥梁。根据重要先行原则，文档就成为了首要因素，建议接口文档先行，也就是 API-First，没有接口文档前端几乎无法开工。
有了API文档，前端通过mock平台（easymock、apifox）解决接口调试+数据Mock的问题，后端默默开发业务代码。
如果双方能这样和平的发展下去，世间是如此静好，但技术是不断变革的，随着后端的微服务化的出现，及大中台概念的产生，后端的开发越来越原子化，由此诞生出了新的问题。

• 一个页面需要请求的接口太多，前端希望后端做接口聚合，减少请求次数，后端则认为接口是根据微服务划分职责的，无需耦合
• 后端提供的接口返回不是前端需要的数据，需要对数据进行多次整理，才能拿到想要的数据
• 每一次的后端接口变更，前端都要进行发布，特别是基础的公用接口，需要同时发布很多应用，带来产线的问题

  独立自主（BFF时代）

随着微服务的盛行，后端数据接口被拆分独，假设现在前端需要一些数据，可能都依赖几个微服务，需要作数据聚合。而与此同时，作为离用户最近的前端，面对各种移动设备，每个客户端的数据类型要求不同，诸如移动端所需数据并不多，需要做数据拆解。

经典对话：

前端：能封装个接口么，现在给的接口前端用起来不方便，要请求好几次，数据不能直接使用
后端：现有架构就是这么设计的，我只是原子化接口
前端：多封装一下接口而已，怎么又扯上架构了
后端：......我们就是这么设计的
前端：......

求人不如求己，借助node服务，前端也能写后端服务层代码了，依赖于koa,egg,nest这些服务端框架，前端自己进行接口聚合，独立自主自理更生，BFF（Backends For Frontends）框架诞生了。

BFF优点：

• 前端要求将与后端问题分开。这更容易维护。更容易维护和修改API
• 客户端应⽤程序将少了解后端结构，这将使其更有弹性更具弹性。
• 服务器错误⼤部分时间都没有毫⽆意义。⽽不是直接返回错误服务器发送，⽽BFF可以映射需要向⽤户显⽰的错误，这将改善⽤户体验。
• 多个设备类型可以并⾏调⽤后端 ，虽然浏览器正在向浏览器BFF提出请求，移动设备可以执⾏相同的操作。它将有助于更快地获得服务的回复。
• 可以隐藏某些敏感信息，并且在向前端发送响应时，可以省略对前端的不必
  要的数据。抽象将使攻击者更难瞄准应⽤程序。
• 应⽤程序的不同部分可以很容易地由不同的团队处理，提⾼开发速度。

---

总结

前后端从最开始的后端一肩挑，到前后端完全分家，分开发展，然后发展到前端开发人员重新拾起了后端的开发技能，每一步的变化都代表者技术变革对于我们的影响。
所谓天下大势分久必合，合久必分，或许下一步的Web3.0的到来会给我们带来新的变化