8 篇博文 含有标签「BFF」

AI 产品做到一定阶段，团队里最容易出现的争论往往不是“模型还够不够强”，而是“这件事到底该放哪一层”。前端觉得后端不该管这么多，工作流觉得前端偷偷做了编排，模型层又被塞进越来越多业务判断。分层一旦乱，后面几乎每个需求都会打架。

这两年我越来越觉得，AI 产品里的 BFF 又变得重要了。但它重要，不是因为我们突然怀念传统前后端分层，而是因为很多团队在 AI 功能早期图快，把会话拼装、模型选择、权限裁剪和供应商切换都散落在不同地方，后面一扩展就开始失控。

Next.js 13 的 Route Handler 出来之后，很多人会自然地想到一个方向：既然前端项目里也能写接口，是不是可以把 BFF 这一层直接揉进去？我觉得答案不是简单的“可以”或“不可以”，关键还是边界。

很多团队把“聚合”这个词说得很泛，结果就是网关想做一点、BFF 想做一点、下游服务也顺手拼一点，最后谁都说不清真正的入口在哪里。

做 BFF 的时候，最容易被忽视的一点是: 你聚合得越多，单个接口的失败面就越大。一个页面接口背后挂了三四个服务，任何一个超时都可能把整页拖慢。

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

BFF 最容易让团队上手的价值，是它能把前端要的多个接口结果拼成一个更顺手的响应。但编排一旦做顺了，也特别容易越界。

2021 年很多团队开始把 BFF 当成前后端之间的稳定缓冲层，但一旦请求量上来，BFF 很快就会遇到一个现实问题: 要不要在这一层加缓存。