我们当年是如何真实落地BFF的?

一听到BFF，你是不是会有一连串的疑问? 比如：

是前端团队实现BFF呢? 还是后端团队实现BFF呢?
那前端团队实现BFF是使用node.js吗? 那后端团队实现BFF是用serverless，云函数之类的，还是直接堆服务器? 另外要用到传说中的GraphQL‌?
那到底要几个BFF呀?

下面我就说一下，我们当年具体是如何落地BFF的。

在开始之前，我想说一句，任何技术架构，一定要根据自己的团队的实际情况和公司业务情况来，切记。不要说，看到网络上某些文章，头脑一热，就开始要兴致勃勃的去实践了。还美其名曰，按照标准来。

当时我们具体是这么干的：

为什么当时BFF由后端来搞

原因是，我们认为BFF是聚合编排层，具有强业务属性，另外还有自己的缓存和存储，这块不可能交个前端团队的。

至于为啥是通过堆机器来搞，而不是采用serverless，那是因为我们当时的技术团队，没有人熟悉serverless，也没有人有这块实实在在的实战经验，就更不用谈什么对应的基础实施的健全性了。

这个当然是我定的，因为我当时管的电商技术部门，组织架构我是这么分的：

且我也认为电商线，大的，就是如我上面那样划分的。然后每条线都有自己的前后端开发，测试，和产品经理。

每次大需求一来，横跨三条线的。那么各条线的人都内部跟自己线内的同事对接就可以了。

这是为了效率，因此搞了：

那这么干的话，前端是不是还得自己聚合一下，对的，超复杂页面，的确如此。但是我们认为这是可以接受的。其实也就那么几个复杂页面会出现这种情况。

剩下的基本上，都是对接自己的BFF层就可以了。

再者，超复杂页面，你去调用一个超级大的BFF的一个接口，我们认为也是不可行的，太危险了。因为粒度实在太粗了，适当的时候，让前端多调用几次，反而是更好的。

好。那么这么整后，整个的架构是如何的呢? 如下图：

那么这里可能有人会问，我们公司体量小，是不是只搞一个BFF就可以了。当然没问题。我上面那样做，是根据我们的实际情况来的。

其实很多小公司，一个BFF就可以了。

当然还会有人问，可不可以独立出一个中间层团队来，这波人专门去做这个BFF层的开发呢? 当然可以。

像我当时待过的一家大厂，就是这么干的。光是中间层研发团队，就超过70号人了。

当有这样的独立的中间层研发团队后，其他的职能技术团队，可就幸福了。因为他们只需要很专注很纯粹的写RPC接口就行了。剩下的不用管了。中间层团队会过来对接的。

不得不说，效率实在太高了。当然，公司也得有钱哈，能养得起这么大的中间层技术团队。

BFF怎么落地，没有标准答案，只有适配答案。后端做还是前端做，取决于BFF里业务逻辑的比重；堆机器还是上serverless，取决于团队对技术的掌控程度；拆几个BFF，取决于业务线的规模和团队的组织方式。这三件事的判断依据都不是技术上的优劣，而是人和组织的现实约束。

很多团队讨论BFF，容易陷入技术选型的争论：GraphQL还是REST，serverless还是传统部署，Node.js还是Java。但这些争的是手段，不是问题本身。BFF要解决的问题是确定的------微服务拆细之后，谁来组装数据。手段根据团队实际情况来选就行，选什么不重要，选完能跑稳才重要。

最近在知乎出了

专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：

它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」

当前星球里免费看的专栏是：

知识星球内后续将推出20+个付费专栏，覆盖电商全链路：

从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。

我的知乎账号: