Backend For Frontend

很多团队为什么最终还是不选择BFF，交由各个前端去异步组装数据？

🔍 团队常见考虑

1. 开发成本低
   • 直接在前端 async/await 调用多个微服务接口即可，前端团队能独立完成，不需要后端额外开发和维护一层服务。
   • 对一些小团队/初创项目，少一层就是少一份维护成本。
2. 灵活性高
   • 前端可以根据界面需求自由组合接口调用，而不用依赖后端改接口。
   • 迭代 UI 时，只要微服务接口稳定，前端就能快速调整数据拼装逻辑。
3. 初期流量/性能压力小
   • 如果用户量不大，多几个 HTTP 请求并不会造成太大性能瓶颈。
   • 在 MVP 或早期版本中，前端拼装更快上线。
4. 减少后端变更
   • BFF 本质上是“接口聚合”，一旦有了，就要跟随前端场景频繁变更。
   • 有些团队担心 BFF 会成为“第二个前端”，需要持续人力维护。

❗ 但是，这种方式的问题也很明显

1. 前端与微服务强耦合
   • 前端必须知道每个微服务的接口、参数、返回模型。
   • 微服务一旦有变更，所有前端都要改，维护成本反而更大。
2. 性能问题
   • Web 或 Mobile 往往需要拼接多个服务的数据，如果每次都要发多个请求，页面加载时间就会变长（尤其是在移动网络环境下）。
   • 并发调用能部分缓解，但依然存在 网络延迟累加 问题。
3. 安全问题
   • 前端直接调用多个微服务，就意味着这些服务都要暴露在网关/公网。
   • 这增加了攻击面，也可能泄露内部服务的接口结构。
4. 不同前端差异大
   • Web、iOS、Android、小程序的需求差异很大。
   • 如果没有 BFF，每个前端都要写一套复杂的拼装逻辑，重复劳动严重。

📌 一般实践规律

• 小团队 / 初期产品 → 倾向前端 async/await 拼装，成本低，上线快。
• 大中型团队 / 成熟产品 → 会引入 BFF，尤其是当：
  • 前端多端共存（Web + iOS + Android + 小程序）
  • 微服务规模较大，接口复杂
  • 有安全/性能要求（如低延迟、减少请求数）

👉 总结：

“前端 async/await 拼装” 适合快速开发、成本敏感的团队；而 “新增 BFF 接口” 更适合复杂场景、追求性能和可维护性的团队。

🎯 真实原因（常见于团队里）

1. 后端排期紧张 / 没有人力
   • 后端通常优先做“核心业务逻辑服务”，比如订单、支付、库存这些。
   • BFF 属于“体验优化层”，对业务 KPI（营收、成交量）没有直接影响，所以容易被排在低优先级。
2. 后端不愿意背锅
   • 一旦有了 BFF，前端需求变化就会变成后端改接口。
   • 有些后端团队会觉得：“这不就是前端的数据拼接吗？你们自己拼一拼不就好了”。
   • 换句话说，他们担心 BFF 变成**“第二个前端”**，增加自己的工作量。
3. 技术能力不足 / 缺少经验
   • 很多团队其实没做过正儿八经的 BFF 或 GraphQL，缺少最佳实践。
   • 他们不确定：BFF 放在哪？怎么跟网关结合？怎么做鉴权？要不要缓存？
   • 于是干脆保持“传统的 API Gateway + 微服务”模式。
4. 职责划分不清晰
   • 有的公司里，前端和后端之间边界模糊：
     • 前端想要的接口是“场景驱动”的。
     • 后端维护的接口是“领域驱动”的。
   • 这种矛盾没有 BFF 来承接，就只能前端自己 async/await 拼。
5. 短期思维
   • 短期内 async/await 拼装不影响上线速度。
   • 长期的性能问题、维护成本，往往要等到业务复杂或团队壮大后才暴露。
   • 所以很多团队“能凑合就凑合”，直到不得不重构。

---

🏷️ 现实中的结果

• 小公司/创业团队：常见前端拼装，因为“能快点上线最重要”。
• 中型团队：经常出现“前端很痛苦，后端说没排期”，最后前端不得不拼命写 async/await。
• 大型团队：一般会在 技术平台组 或 中台 层面推动 BFF，因为前端多端差异太大，不搞 BFF 成本更高。