关于javascript:前后端相煎何太急

9次阅读

共计 1907 个字符，预计需要花费 5 分钟才能阅读完成。

前沿：哈喽，我是树酱。明天分享的水文是对于前端与后端之间 battle 的那些事，自从前后端拆散之后，这场分家带来了不少沟通问题，甚至产生 battle。咱们先回顾下前后端 battle 的前世今生

依稀记得刚大学毕业那会，电脑上装置的第一个 IDE，不是 Webstorm 也不是 VScode，而是 IntelliJ IDEA。因为开发前端我的项目，须要跑残缺的一个 JAVA 程序，各种 maven 配置，而后在后端编写的 JSP 文件根底上再进行前端开发，换句话说就是“二次开发”，当初想想过后编译慢的场景，历历在目。换句话说就是前端开发重度依赖环境

阿乐同学：我记得我过后就只提供 HTML 代码，而后用 Sublime 做编辑器就好了，而后最初再整合到 JSP 中去

这就是另外一种模式，前端负责输入 demo Html，而后交给后端去套模版

只是说齐全交由后端去整合，出错率较高，遇到 Bug 解决起来也很麻烦，须要单方协同解决。换来的更多的沟通老本。因为前后端的职责很容易纠缠不清，耦合性太强，最初还可能导致 battle。

总结产生 battle 的点👇：

1. 前端开发重度依赖环境，导致每次批改文件编译工夫过长，考验前端开发者的急躁
2. 当利用须要降级时，无奈独自对前端、后端独立降级。而是对整个单体利用整体降级
3. 后端将前端事后开发好的 html 页面，嵌入到 JSP 文件后，理论款式成果偏差过大

前端 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，字段不对立导致沟通老本晋升

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

会产生相似上面的 battle 场景👇：

前端同学和后端同学都各有各的情理，有没有一种解决方案能够化解这种难堪的场景，于是就有了 BFF，BFF 全称是 Backends For Frontends(服务于前端的后端)

在 BFF 层上面是各种后端微服务，在 BFF 下层则是各种前端利用（多端利用），向下调用后端为服务，向上给客户端提供接口服务，后端为 BFF 层的前端提供的的 RPC 接口，BFF 层则间接调用服务端 RPC 接口拿到数据，按需加工数据，来实现整个 BFF 的闭环（以 Node+GraphQL 技术栈为主）

BFF 的呈现的确解决了蛮多前端后的沟通老本，彼此也友善了很多，对话就演变成这样