wanghaisheng commented on issue #3488: URL: https://github.com/apache/apisix/issues/3488#issuecomment-771519003
[5.2] GraphQL as an API Gateway 模式 在这个模式里，GraphQL 接管了前端的一整块数据查询需求。 前端不再直接调用具体的 RESTful 等接口，而是通过 GraphQL 去间接获取产品、订单、搜索等数据。 在 GraphQL 这个中间层里，我们将各个微服务，按照它们的数据关联，整合成一个基于 GraphQL Schema 的数据关系网络。前端可以通过 GraphQL 查询语句，同时发起对多个微服务的数据的获取、筛选、裁剪等行为。 值得一提的是，作为 API Gateway 的 GraphQL 服务，可以在其 Resolver 内，向前面提到的 RESTful-like 的 GraphQL 发起查询请求。 如此，既避免了前端需要一对多的问题，也解决了 API Gateway GraphQL 需要请求 RESTful 全量数据接口的内部冗余问题。让服务到服务之间的数据调用，也可以做到更精确。 GraphQL 服务是一个对数据消费方友好的模式。而数据消费方，既可以是前端，也可以是其它服务。 当数据消费方是其它服务时，通过 GraphQL 查询语句，彼此之间可以更精确获取数据，避免冗余的数据传输和接口调用。 当数据消费方是前端时，由于前端需要跟多个数据提供方打交道，如果每个数据提供方都是单独的 GraphQL，那并不能得到本质上的改善。此时若有一个 Gateway 角色的 GraphQL，可以真正减少前端调用的复杂度。 [5.2.1] 两类 GraphQL API Gateway 服务 同样是 API Gateway 角色的 GraphQL 服务，在实现方式上也有不同的分类。 1）包含大量真实的数据操作和处理的 GraphQL 2）转发数据请求，聚合数据结果的 GraphQL 第一类，是传统意义上的后端服务；第二类，则是我们今天的重点，GraphQL as BFF。 这两类 GraphQL 服务的要求是不同的，前者可能包含大量 CPU 密集的计算，而后者总体而言主要是 Network I/O 相关的行为。 许多公司并不提倡使用 Node.js 构建第一种服务，不管是构建 RESTful 还是 GraphQL。我们也一样。 https://cloud.tencent.com/developer/article/1477870 ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
