缘起
今天听了一群大佬们分享BFF，结合小编自己的理解和积累，分享给各位童鞋!
何为BFF
BFF其实是Backend For Frontend，就是服务于前端的后端，直白点就是中间件，中转站，前端做一部分后端的活，抢后端的饭碗，让后端事情更少，哈哈哈！
BFF的价值
很多童鞋问了，BFF增加了前端的工作量，好像后端工作量也没少多少，那么价值在哪里！
我们知道任何技术的更新和发展，必然是因为其价值，下面我们先来谈谈BFF的价值！
应用场景：
假如公司现在有很多业务，用户们可以通过手机端，PC端，Pad端等不同的设备访问，但是不同的端口因为各种原因，返回的数据不一样，简单的说，手机端返回的数据必然不能像pc那么多，更要命的是，不同的设备还有差异返回，那么如何解决这类问题！
传统的做法：
后端自己做适配，不同的终端后端自己做转化，那么问题来了，以后增加终端类型，后端要不断增加适配。更糟糕的是，假如需要请求其他的业务线接口，那么还需要继续做转化，如果后端是多语言的，难以想象！
BFF做法：
上面提到了，BFF其实可以看作中间件，那么后端不需要关心多少个终端过来的数据，前端也不需要关心后端的语言是否一致，后端的接口域名是否一致，因为BFF都会帮你解决！
更重要的是，如果某个业务场景变了，后端很忙，没时间和前端联调，前端可以按照后端提供的一系列接口文档，自己完成接口调试。举个简单的例子，一开始业务场景是需要A接口的A字段，现在还需要B接口的C字段，A和B接口都存在，且都有字段，但是A和B接口不是同一个域名，传统的做法是A和B接口并非请求，然后拼接，还需要等后端联调啥的。现在的做法是，前端直接请求BFF的C接口，C接口按照参数获取A和B接口的返回值，然后返回给前端，节省了大量联调时间，提高了效率！
BFF除了上面的价值，还有其他很多价值，比如很多优化浏览器层面不能做，那么BFF可以在服务端处理。又比如降低运维成本，减少重复工作，降低发布时间。关键是看你对BFF的定义，或者是你想用BFF做啥？
BFF能力
上面我们说过了，BFF能力是按照你想要的赋予的，简单来说，就是BFF承担了原来后端要承担的哪些能力，轻后端的感觉啊！
我们从两个角度来科普这个问题：
- 传统
- 最新
传统
传统上，其实好多类似BFF功能的，举个例子GraphQL，这类其实是早就出现的，它的作用是前端可以根据需要获取自己想要的值，减少接口请求数据返回（节省流量，提高效率）。但是这个有个问题，GraphQL这个后端也可以布置，那么容易造成前端和后端扯皮，比较前端认为这个应该是后端布置的，后端则认为相反！
类似的还有好多：Type-GraphQL，Appolo GraphQL，DataLoader，Prisma ORM等等！
最新
最新BFF其实是自己定义，比如我想让BFF有登录权限，网关能力，请求认证，数据重组，协议转换，安全校验，路由服务，不同租户数据隔离，灰度发布，api转发等功能，那么我需要在node中增加这些能力，如果我想要减少工作量，那么有些功能我可以借助传统的，比如使用GraphQL等！
这里重点说个问题，我们可以把后端语言解析成ts，比如用工具把java模型解析成ts模型，解析后的ts模型可以再导出成文档，方便客户端的童鞋按照文档调用api，提高效率。同时BFF调用后端api的情况下，也可以按照ts处理传参和返回，保持前后端一致性，提升效率。也可以和serverless结合起来使用的，这样自己就不需要管BFF线上部署，技术的理念是组合和相通的，关键看你符合选择！
缺点
缺点无非就是两个
- 前期部署调研和项目改造迁移的成本，这个大家都懂的，这里不多做解释
- 因为涉及接口转发，所以效率会低一点，但是我们可以通过设立多级缓存来解决问题，比如menory cache，local cache，oss cache等。也可以测试接口时间，在特定的时候把请求降级处理，来提升客户体验！
是否应该上BFF
上面说了这么多，其实上不上BFF还是要看公司具体是业务，以及团队人员配置，也要考虑时间成本和技术成本。小编一直认为，没有最好的技术方案，只有最合适的方案！
尾声
愉快的时光总是短暂的，今天的分享到这里了，小编祝大家节日快乐！学习使我快乐，越学习，感觉自己不知道的地方阅读，根本停不下来！