要被 BFF 玩亖了！

大家好，我是晨光。之前好像说过，团队开始搞各种 BFF 来着，一开始写的时候挺痛苦的，因为 BFF 层的模块和客户端的 View 都是一个人负责。既要设计契约，又要画 UI。好处就是一个人比较熟，少了沟通成本，坏处就是累，既要改这里，又要改那里。

1、设计 BFF 的初衷

原本设计 BFF，是为了减少大家的工作量的。比如多端一致，全流程一致等等。统一到 BFF 里面，改动一个，其他地方也都能同时生效，但有利有弊。

利：多端都能追齐

弊：万一有问题，一个挂，全部挂

原本没有 BFF 时

1）从 SOA 到客户端还有一个中间层的，现在有了 BFF，替换了JAVA 写的中间层，改用 NodeJS 了，前端原本有一个 ViewModel ，假如 BFF 契约定义的合理，就可以充当这个角色。

2）新需求验证，总会挑一个大流量的页面做新功能，实验验证，效果好再追齐

3）做需求只用管客户端逻辑，数据处理都是服务下发

4）改动客户端的需求，可能需要全流程都改，涉及五六个项目

5）同一个功能模块，由于技术栈不统一，跨团队等，模块组件无法复用

现在有 BFF

1）产品总希望需求只提一次，但同时满足全流程或者多端

2）既要关心契约字段，还有 UI 视图，工作量基本都 double

3）改动需求，大部分时候都是只用改动俩项目，如果多项目的情况大部分时候都是x2，客户端+BFF

4）发布是一个头疼的问题，以前可以搭车的发布，可能现在需要自己单独发布监控

5）同一个功能模块，一次改动，可跨技术栈，跨页面实现统一

2、被玩坏的 BFF

我们都知道，定义契约要语义化，要具有拓展性。

语义化：根据字段名能推测出这个字段是干啥的；

拓展性：比如某个字段未来可能会频繁修改，我们如果定义成 Object，每次新增字段都得修改契约，但如果定义为 key value 的 list 结构，或者 model 的 list 结构，就不需要频繁变更契约

那怎么算是被玩坏了呢？契约和 UI 强绑定，并且不语义化，不具有拓展性，契约层级嵌套过深

上面这个例子，和视图层强相关，但是第一行，第二行，第三行，第四行..... 要是没有页面，完全不知道是什么，只能知道它的位置第几行。

上面的定义种，我们把它定义的更语义化了，虽然不知道视图上放在第几行，但是假如哪天，需要调整视图排列顺序，第一种方式就有些不合适了。

3、快被玩亖了

有了 BFF 之后，以前多个人的工作，转变为一个人的工作量，记得上个迭代，一个很小的功能，就改动了 4 个仓库！除了开发，还要外加测试、发布。

另一个小伙伴，他是应届生，排给他的需求也不大，但是涉及的页面多，基本上一个页面就有2 个仓库，客户端+BFF，总共加起来也有 5 个项目，排期了 5d 他觉得不太够。一整个痛苦面具，笑亖了

由于部分客户端页面技术栈是 Flutter，和 RN、Web 有一些差异，无法往低版本覆盖发布，因此导致新功能只能在最新版上生效。

原以为有了 BFF，大家工作上会轻松些，最理想的情况是，只改 BFF，发布后多版本都能生效。但现实是，新需求每次都得新加字段，老字段改动还得控制客户端版本，客户端的改动也只能最新版生效。果然就是理想很丰满，现实很骨感。

前端要开发和维护 BFF 的逻辑，有时候也需要后端开发再新增字段，协助和支持 BFF 的开发。这一整个流程下来，也是增加了整个团队不少的工作量和成本。

但相比于原来要跨端跨页面同步需求的，现在只用改一个 BFF + 客户端，也是节省了不少人力。但对于现在单个开发，工作量是只增没减的。

上图只是举例说明的一个示意图，左边是没有 BFF 时，改动全流程的某个同类型的模块，可能需要动到多个页面以及多个服务项目。右边有 BFF 之后，可能只需改动两个项目。对整个团队成本是有减少，但对单个人，工作量是有增加。

4、总结

BFF 的设计初衷是为了提供更好的前后端分离和协作方式，定制化API，优化性能，并提供安全性保障。可以用来提高开发效率、灵活性和用户体验。

有利有弊，在某些场景下，BFF可以提供很多好处，如上面提到的那些，但在其他场景下，可能会带来一些额外的复杂性和开销，开发人员的工作量增加等等，需根据具体情况来评估是否适合使用 BFF，避免 BFF 的滥用。

以上，全文完，有收获记得点个赞呀👍～