前沿：哈喽，我是树酱。明天分享的水文是对于前端与后端之间battle的那些事，自从前后端拆散之后，这场分家带来了不少沟通问题，甚至产生battle。咱们先回顾下前后端battle的前世今生
1.远古时代 (web1.0 - MVC架构)
依稀记得刚大学毕业那会，电脑上装置的第一个IDE，不是Webstorm也不是VScode，而是IntelliJ IDEA。因为开发前端我的项目，须要跑残缺的一个JAVA程序，各种maven配置，而后在后端编写的JSP文件根底上再进行前端开发，换句话说就是“二次开发”，当初想想过后编译慢的场景，历历在目。换句话说就是前端开发重度依赖环境
阿乐同学：我记得我过后就只提供HTML代码，而后用Sublime做编辑器就好了，而后最初再整合到JSP中去
这就是另外一种模式，前端负责输入demo Html，而后交给后端去套模版
只是说齐全交由后端去整合，出错率较高，遇到 Bug 解决起来也很麻烦，须要单方协同解决。换来的更多的沟通老本。因为前后端的职责很容易纠缠不清，耦合性太强，最初还可能导致battle。
总结产生battle的点：
- 1.前端开发重度依赖环境，导致每次批改文件编译工夫过长，考验前端开发者的急躁
- 2.当利用须要降级时，无奈独自对前端、后端独立降级。而是对整个单体利用整体降级
- 3.后端将前端事后开发好的html页面，嵌入到JSP文件后，理论款式成果偏差过大
2.铁器时代 （web2.0 -MVVM架构）
前端MVVM架构的呈现促成了前端开发与后端业务逻辑的拆散，真正实现“分家”：分工帮助、各司其职、回绝捆绑。
这时候就须要一个“沟通桥梁”：API ，再通过ajax调用实现前后端之间的合作沟通。两者也解耦了
API消费者（前端）：通过接口文档理解接口信息，聚焦点：承受数据、解决数据、解决渲染逻辑
API生产者（后端）：提供接口以及接口文档 聚焦点：提供数据、提供API文档
开发流程也开始转变：
- 后端编写和保护接口文档，在 API 变动时更新接口文档
- 后端依据接口文档进行接口开发
- 前端依据接口文档进行开发 + Mock平台
- 开发实现后联调和提交测试
啊乐同学：那前后端拆散后，是后端同学先开发还是前端同学先开发？
从下面的开发流程咱们能够看出，分家之后，接口文档是最要害的沟通桥梁。依据重要后行准则，文档就成为了首要因素，倡议接口文档后行，也就是 API-First，没有接口文档前端简直无奈动工。
啊呆同学：对于前端同学接口联调用postman调试，mock用Yapi或者RAP2来生产假数据，有没有更好用的工具一步到位？
以前我也是左手一个postman，右手一个yapi，两头码着code
你能够试试 Apifox
官网介绍：Apifox 是 API 文档、API 调试、API Mock、API 自动化测试一体化合作平台，定位 Postman + Swagger + Mock + JMeter
前端同学能够用Apifox来解决接口调试+数据Mock的需要
上面分享一个实战页面截图
但新的开发流程也裸露出新的battle点
总结产生的battle点：
- 1.一个页面须要申请的接口太多，前端心愿后端做接口聚合，缩小申请次数，后端则认为接口是依据微服务划分职责的，无需耦合
- 2.后端提供的接口产生变更，但接口文档却没有同步，或者后端提供接口缺失，前端无奈失常mock等
- 3.字段不对立：举个例子，手机号码的字段，有的返回 mobilePhone，有的返回 PhoneNumber，字段不对立导致沟通老本晋升
3.白银时代 （BFF时代）
随着微服务的流行，后端数据接口被拆分独，假如当初前端须要一些数据，可能都依赖几个微服务，须要作数据聚合。而与此同时，作为离用户最近的前端，面对各种挪动设施，每个客户端的数据类型要求不同，诸如挪动端所需数据并不多，须要做数据拆解。
会产生相似上面的battle场景：
前端同学和后端同学都各有各的情理，有没有一种解决方案能够化解这种难堪的场景，于是就有了BFF，BFF全称是Backends For Frontends(服务于前端的后端)
在BFF层上面是各种后端微服务，在BFF下层则是各种前端利用（多端利用），向下调用后端为服务，向上给客户端提供接口服务，后端为BFF层的前端提供的的 RPC 接口， BFF 层则间接调用服务端 RPC 接口拿到数据，按需加工数据，来实现整个BFF的闭环（以Node+GraphQL技术栈为主）
BFF的呈现的确解决了蛮多前端后的沟通老本，彼此也友善了很多，对话就演变成这样
- 后端：这些微服务都在这里了，你看着组合，有问题找我
- 前端：行，我看着组合
对于BFF感兴趣的童鞋能够浏览树酱之前的 你学BFF和Serverless了吗?