面试官：BFF 它到底解决了什么问题？又带来了哪些新问题？

随着后端微服务架构的普及，以及客户端形态（Web、iOS、小程序、桌面端）的日益多样化，我们前端开发常常会面临一个很尴尬的局面：

后端提供的API，往往是通用的、面向数据的，而我们前端需要的，却是定制化的、面向UI的数据。这就导致前端需要写大量的逻辑，去请求多个接口、合并数据、做各种适配，苦不堪言。

为了解决这个矛盾，BFF（Backend for Frontend） 个架构模式，应运而生。

今天，我们就来深入聊聊BFF，我会用最直接的方式，解释清楚它是什么、解决了什么问题、又带来了什么新问题。而且这一类问题可能面试当中会遇到。

BFF是什么玩意儿

BFF，全称 Backend for Frontend ，直译过来就是"服务于前端的后端"。

它不是一个具体的技术框架（像Express或Koa），而是一种架构模式。

它的核心思想是，在通用的后端服务（Microservices）和前端应用（Client）之间，增加一个中间层 。这个中间层，专门为某一个或某一类前端应用量身定制，充当一个适配器的角色。

不使用BFF和使用BFF的架构变化，简单参考如下图👇：

BFF到底解决了什么核心痛点？

引入一个新层，一定是为了解决某些无法忍受的痛点。BFF主要解决了以下三个问题：

减少网络请求

一个前端页面，常常需要来自多个微服务的数据。比如一个用户中心页面，需要"用户信息"、"订单列表"、"积分信息"，前端不得不发出3次API请求。

BFF的解决方案 ：BFF可以在服务端，通过高速的内网，代替前端去调用这3个微服务，然后将数据聚合在一起，通过一个接口，一次性返回给前端。

JavaScript 复制代码

// 一个BFF里Express路由的伪代码示例
app.get('/api/profile-page', async (req, res) => {
  try {
    const userId = req.user.id;
    
    // 在服务端并行请求多个微服务
    const [userInfo, orderList, points] = await Promise.all([
      userService.getUser(userId),
      orderService.getOrders(userId),
      pointService.getPoints(userId)
    ]);
    
    // 聚合数据后，一次性返回给前端
    res.json({ userInfo, orderList, points });
  } catch (error) {
    res.status(500).json({ error: 'Failed to fetch profile data' });
  }
});

适配数据

后端通用API返回的字段通常大而全。比如一个用户接口返回50个字段，但前端可能只需要其中5个。多余的45个字段，白白浪费了用户的流量。

BFF的解决的是 ：BFF 可以根据前端UI的需要，对数据进行适配，只返回前端需要的那部分数据，甚至可以根据前端的需要，直接调整好数据格式。

解耦前后端，提升开发效率

前端与后端微服务的实现细节紧密耦合。一旦某个微服务的接口发生变化，前端就必须跟着修改。

BFF的解决方案 ：BFF为前端提供了一个稳定的API契约。即使后端的某个微服务下线了、或者拆分了，只要BFF对前端的接口保持不变（BFF内部去适配这种变化），前端的代码就可以一行都不用改。这使得前后端可以独立、并行地开发，极大地提升了协作效率。

BFF又带来了哪些新的问题？

任何架构的引入，都是一种权衡的结果。BFF在带来好处的同时，也带来了新的问题。

增加了系统的复杂度和维护成本

这是最直接的问题。我们多了一个需要开发、部署、监控和维护的服务。系统的调用链路变长了，排查问题的难度也相应增加。这对于团队的DevOps能力和人力投入，都是一个考验。

带来了团队职责和归属的边界问题

一个经典的问题："BFF到底应该归前端团队管，还是后端团队管？"

前端管：好处是前端最了解自己的需求，沟通成本低，迭代快。坏处是，前端同学可能普遍缺乏后端开发、运维、安全等方面的经验。
后端管：好处是后端同学经验丰富，能保证服务的稳定性。坏处是，BFF很容易又变成了一个通用服务，后端同学可能无法理解前端对API的特殊需求，BFF层会成为新的沟通瓶颈。

（我们团队目前的实践是：BFF由前端团队主导开发，但后端团队需要深度参与Code Review，并协助制定运维规范。）

说了那么多优缺点，那我们如何选择呢？

当你的应用还很简单，后端就是一个单体服务，前后端沟通顺畅时，引入BFF就是过度设计，有一种用牛刀杀鸡的感觉。尤其是当前团队规模非常小，没有足够的人力去维护一个额外的服务时，不要使用BFF。

如果后端架构演化成了一个复杂的微服务 体系。而且产品有多个、形态各异的前端（比如Web端、iOS端、安卓端、小程序），它们对API的需求差异很大时，采取选择BFF架构。

它是一种架构上的权衡。它用增加一个维护层的成本，换取了前后端解耦和提升客户端体验的收益。对于复杂的、多端的现代应用来说，这笔交易，通常是划算的。🤔

但最后还是量身而定，不要盲目跟随。这你们怎么看🤞