API 网关选型及包含 BFF 的架构设计( 二 ) 一背景介绍下图是我从网络上

api数据裁剪
接口编排
接口调用

这层有的公司会按业务进行多个BFF的建设，在BFF中又有可能拆成多个服务，比如支撑首页的，支持列表页的，或者只有一个服务，支撑某个应用的所有请求的。
有了BFF层，前后端就会更好的解耦，前端不用再调用多个接口，然后再组织数据，微服务后端也只需要关心自己服务边界内的事情。
然而在实践的过程中会出现一些问题：

大量业务逻辑从前后端集中在了BFF层
BFF层逻辑复杂，代码量越来越大，难以维护
BFF API版本维护复杂
前端端接口职责不清，扯皮的结果就是放在BFF层

以上是我真实遇到过的场景。所以在后面的架构设计和实施中，这些情况会尽量避免，但没有从技术上解决根本问题。直到 GraphQL 的出现，让我眼前一亮，给了我一个很好的解决方案。关于GraphQL的搭建，数据交换等细节这里就不展开说了，感兴趣的可以从网上找到很多资料。
下图是我从网络上找的一个符合我心目中的理想架构。

文章插图
图片来源于网络
【API 网关选型及包含 BFF 的架构设计】说起来简单，做起来没那么容易，细节是魔鬼，每利用一个新的技术都会经历一波打怪升级的过程。不过总体来说利用GraphQL确实能从理论上解决上面所说的问题。而重点是如何将它结合进你的系统架构中，并且发挥出它的优势。架构很多时候是在做权衡和选择