Skip to content

Instantly share code, notes, and snippets.

@iamnivekx

iamnivekx/bff.md

Created June 11, 2020 03:46
Show Gist options
  • Save iamnivekx/15860f36592c1f4964b6e953a0702abe to your computer and use it in GitHub Desktop.
Save iamnivekx/15860f36592c1f4964b6e953a0702abe to your computer and use it in GitHub Desktop.
Download ZIP
Raw
bff.md

基本介绍

我觉得这个的架构演化和我们遇到的问题应该是很类似

调研

使用样例

偏向端， api gateway

偏向产品, GraphQL

里面有 携程无线 Netflix SoundCloud的架构参考

困境和思考

里面介绍了BFF的一些问题，同时也提供了划分的参考与比较

上周分歧

上周的分歧主要是在 bff是按照UI(端)来划分还是按照产品来划分

个人思考与观点

观点

我觉得还是按照 UI(端) 来划分会更加合理吧，如果pos和bo都需要执行某块的功能，我们可以把这个service提取出去，由他们对应的bff去调用，这样职能更加明确，bo或者pos需要修改某个功能，这样是不是就只需要测试对应的bff就可以了，当然如果有一个api鉴权配合GraphQL也是可以的

若按照UI(端)划分
优势

职能清晰，哪端的问题，对应的bff端做修改，无需复杂的权限鉴定

劣势

当多端都需要使用的接口，会显得代码冗余，同时需要一个Api Gateway, 结构可能会更加复杂，服务线会更加的长，维护成本也会比较高

若按照产品划分
优势

bff可以跟着产品走，业务线比较短

劣势

多端的接口都糅合在一起了，单接口修改可能需要影响多端，需要重新测试，还有就是后期会不会发展成一个庞大的系统，当然如果配合 api鉴权 + GraphQL可能会解决大部分的问题

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment