后来公司扩张，业务线越来越多。每条线dou要BFF，于是我们建了一套又一套。打开代码库一kan，惊人的相似：

// 业务线A的BFF
router.get => {
  const data = await fetchData;
  return { code: 200, data };
});
// 业务线B的BFF
router.get => {
  const data = await fetchData; // 几乎一样的逻辑
  return { code: 200, data };
});
// 业务线C的BFF
router.get => {
  const data = await fetchData; // 又一遍
  return { code: 200, data };
});

hen多中大厂dou在悄悄“回退”Node.js中间层，原因就在这儿。我们有4个BFF，业务逻辑重复60%，改一个需求要改3-4处，联调简直是地狱。这种重复劳动，本质上是在浪费我们前端的价值。我们本该花时间研究组件复用、性Neng优化、用户体验，结果天天在写重复的数据聚合代码。

而且成本低得惊人——我是说以前那种模式成本高得惊人。以前BFF服务器7x24小时运行，半夜没人访问也在烧钱。机器、带宽、人力运维，每一项dou是实打实的开销。曾经被视为救星的技术，现在被不少中大厂视为成本噩梦，hen多团队正在悄无声息地回退、替换或砍掉它。

写到这里可Neng会觉得BFF是一个“错误的选择”。但我想说：在那个时间点，BFF就是Zui好的解。 只是技术在进步，语境在变化，我们的解法也得跟着变。

Ru果说内部问题是“慢性病”，那新技术的出现，就是对BFF的“降维打击”。这两年，Serverless和GraphQL的成熟，给了我们新的思路。

我第一次接触Serverless，是帮朋友搞一个小程序。不用买机器、不用配nginx、不用考虑扩缩容。写完代码，serverless deploy，完事。出问题了？kan日志，改代码，再部署。全程不用碰服务器。

而且成本低得惊人。以前BFF服务器7x24小时运行，半夜没人访问也在烧钱。Serverless按调用次数计费，低流量时期几乎不花钱。

// 传统BFF：一直运行
app.listen => {
  console.log; // 半夜也在运行，烧钱
});
// Serverless：按需启动
exports.handler = async  => {
  // 有请求才执行，执行完就销毁，不烧钱
  return { statusCode: 200, body: 'hello' };
};

除非有特殊需求，否则优先用云函数。运维成本几乎为零，咱们前端Ke以真正专注于业务逻辑。这才是我们前端Zui宝贵的品质。

GraphQL刚出来时我们觉得它不就是BFF的另一种形式吗？但用了一段时间才发现，Zui大的改变是：前后端终于有了一份清晰的“契约”。

以前调BFF接口，返回什么全靠kan代码、靠猜。用GraphQL，前端明确声明要哪些字段，返回的数据结构是强类型的，IDE里还有智Neng提示。

# 前端声明要什么
query {
  order {
    amount
    status
    user {
      name
      avatar
    }
    products {
      name
      price
    }
  }
}

Schema优先、强类型契约、按需查询——这些思想，会让你对“前后端协作”有geng深的理解。后端悄悄改了字段？Schema不匹配，直接报错，不用等到上线了才发现。

// GraphQL resolver：聚合逻辑还在但契约geng清晰了
const resolvers = {
  Order: {
    user:  => fetchUser,
    products:  => fetchProducts
  }
};

这几年，后端也在变化。以前他们只管原子接口，现在他们也意识到，面向前端的服务需要geng贴近业务。

// 以前：后端坚持原子接口
GET /user/123
GET /orders?userId=123
GET /products?orderId=456
// 现在：后端提供聚合接口
GET /web/profile?userId=123
// 返回：{ user: {...}, recentOrders: , favoriteProducts:  }

后端团队也开始重视文档、规范字段命名、保证数据契约的稳定性。前端对BFF的依赖，自然就降低了。这并不是说BFF消失了而是它的职责被重新分配了。一部分回到了后端，一部分交给了Serverless，一部分通过GraphQL标准化了。

今天想站在咱们前端的视角，聊聊这场“退潮”背后的真实故事。BFF从崛起到回落，不是一个失败的故事，而是一个成长的印记。它见证了前端从“切图”到“全栈”的探索，也见证了架构演进的必然规律。

即使以后不用BFF了那段经历也是宝贵的。你学会了如何处理并发、如何设计缓存、如何Zuo服务熔断、如何排查线上问题。这段经历，也让我们学会了后端思维：缓存、并发、熔断、限流...这些知识，现在依然在用。

这些Neng力依然有用：

Promise.all, fetchB, fetchC]); // 并发控制
node --inspect-brk app.js // 调试技巧

这些Neng力，会让你成为“geng懂后端”的前端，在协作中geng有话语权。

对于我们每个亲身经历过的人来说重要的是：不要停留在过去的荣光里也不要否定曾经的探索。技术的世界，没有永恒的真理，只有不断变化的语境。保持学习，保持思考，保持对新技术的好奇。

Ru果你问我，现在要不要学Node.js中间层，我的答案是：要学，但不是以前那种玩法。 去学Serverless，去学GraphQL，去学怎么用Node.js解决前端真正解决不了的问题，而不是为了“全栈”的虚名去维护一堆烂泥一样的BFF代码。

Ru果你也经历过BFF的起起落落，欢迎在评论区聊聊你的故事。咱们一起，在这个变化莫测的技术圈里继续折腾下去。