BFF的全名是Backends For Frontends (为前端后端服务)，Sam Newman写了与他的博客相关的文章—— pattern 3360 backendsforfrontends，并
BFF是指服务器在设计API时考虑到不同设备的需求。 这意味着每个设备提供不同的API接口。 它们可能实现了相同的功能，但根据设备的特殊性，对服务端的API访问也各有特点，需要区分处理。 因此，出现了下图所示的设计。
两个客户端都调用BFF层提供的接口，而不是直接访问服务器的公共接口，BFF层再次调用末端的公共服务。 不同的客户端具有不同的BFF层，它们定制了客户端所需的API。 图1和图2的区别在于，是否需要为IOS和android等相似的设备者分别提供BFF，这需要根据现实情况来决定，解决方法因项目环境而异。
那么，采用BFF体系结构并使用多个和通用的单个API的好处是什么？ 最重要的一点是，正如前面提到的，由于可以满足不同客户端的特殊交互对新接口的要求，所以从一开始就设计了相应的设备接口。 如果使用单个通用API，并且最初没有考虑特殊需要，则在出现新请求时可能会出现以下问题：
添加新接口后，接口往往会变得不稳定。 考虑到对现有接口进行的更改，可能需要进行某些联接。 让我们来看看破坏和思考单一作用的简单例子。 由于移动APP的屏幕限制，一个列表页只显示重要信息，而服务端提供统一的API，因此服务端被设计为只考虑web端并返回所有字段信息。 但是，这些对移动端来说是徒劳的。要在优化性能时解决这些问题，必须通过在服务端添加接口或部署相关绑定来解决这些问题。 使用BFF可以大大避免这种问题。
使用BFF的另一个优点是，如果一个客户端需要调用多个不同的服务端接口来实现功能，则可以直接在相应的BFF层创建API，而不影响底层公共服务，并且客户端可以在多个后端
当然，凡事都有利弊，BFF在带来方便好处的同时，也会引起代码重复、开发工作量增大等问题。 因此，使用时要根据现实情况仔细斟酌，符合项目的应用开发背景。 例如，蚂蚁财富使用BFF的场景如下。