Node.js BFF 接口聚合实践

前面聊 BFF 的时候，更多是在讲为什么它存在。到了真正落地时，团队最容易争论的是另一件事: 这层东西到底该做多厚，做哪些事才算合理？

我比较认可的 BFF 边界，不是“把后端接口再包装一遍”，而是只做三种真正有价值的工作：

• 聚合多个后端服务的数据
• 做面向前端页面的字段适配
• 把前端不该承担的流程复杂度收住

一个典型的聚合场景

比如一个内容后台首页，需要同时展示：

• 当前用户信息
• 待审核文章数量
• 最近发布文章
• 系统公告

如果前端自己逐个请求 4 个服务，页面会很碎，错误处理也复杂。BFF 很适合把它们收成一个接口。

async function getDashboardData(ctx) {
  const [user, reviewStats, posts, notices] = await Promise.all([
    userService.getProfile(ctx.userId),
    reviewService.getPendingCount(),
    contentService.getRecentPosts(),
    noticeService.getLatestList(),
  ]);

  return {
    user,
    reviewStats,
    posts,
    notices,
  };
}

BFF 该做什么，不该做什么

该做的：

• 适配页面所需结构
• 合并多服务结果
• 统一鉴权、限流、降级策略

不该做的：

• 重写核心业务规则
• 持有过多独立状态
• 变成第二套后端系统

如果一个需求到了 BFF 层还要写大量复杂业务判断，通常说明边界已经开始偏了。

Node.js 为什么适合做这一层

原因很现实：

• I/O 密集型聚合天然适合 Node.js
• JSON 数据处理方便
• 和前端团队协作成本低

这也是为什么 2021 年越来越多团队开始认真讨论 BFF，而不是只把它当作 PPT 里的一个名词。

聚合层最该注意的坑

真正线上最常见的不是“不会聚合”，而是：

• 下游服务慢一个，整个接口都被拖死
• 一个子服务失败，整个页面直接 500
• 字段转换逻辑散落在多个 handler 里

所以聚合层最好尽早具备：

• 超时控制
• 局部降级
• 统一响应结构

小结

Node.js 做 BFF 最大的价值，不是多写一层，而是把原本分散在前端的服务协调逻辑、字段适配逻辑和错误处理逻辑收回来。只要边界守得住，这层会非常有价值。