缘起
今天听了一群大佬们分享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还是要看公司具体是业务,以及团队人员配置,也要考虑时间成本和技术成本。小编一直认为,没有最好的技术方案,只有最合适的方案!
尾声
愉快的时光总是短暂的,今天的分享到这里了,小编祝大家节日快乐!学习使我快乐,越学习,感觉自己不知道的地方阅读,根本停不下来!