GraphQL和微服务架构

我试图了解GraphQL最适合在微服务架构中使用的位置 .

关于只有一个GraphQL架构作为API网关代理对目标微服务的请求并强制其响应存在争议 . 微服务仍然会使用REST / Thrift协议进行通信思考 .

另一种方法是每个微服务具有多个GraphQL模式 . 拥有一个较小的API网关服务器,将请求路由到目标微服务,并且请求的所有信息都是GraphQL查询 .

1st Approach

将1个GraphQL架构作为API网关将有一个缺点,每次更改微服务 Contract 输入/输出时,我们必须在API网关侧相应地更改GraphQL架构 .

2nd Approach

如果每个微服务使用多个GraphQL模式,那么在某种程度上是有意义的,因为GraphQL强制执行模式定义,并且消费者需要尊重微服务给出的输入/输出 .

Questions

  • 在哪里可以找到适合设计微服务架构的GraphQL?

  • 您如何使用可能的GraphQL实现设计API网关?

回答(5)

3 years ago

绝对接近#1 .

让您的客户与多个GraphQL服务交谈(如方法#2)首先完全违背了使用GraphQL的目的,即提供整个应用程序数据的模式,以允许在单个往返中获取它 .

从微服务的角度来看,拥有无共享架构似乎是合理的,但对于您的客户端代码来说,这绝对是一场噩梦,因为每次更改一个微服务时,您都必须更新客户端 all . 你肯定会后悔的 .

GraphQL和微服务非常适合,因为GraphQL隐藏了一个事实,即您拥有来自客户端的微服务架构 . 从后端的角度来看,您希望将所有内容拆分为微服务,但从前端的角度来看,您希望所有数据都来自单个API . 使用GraphQL是我所知道的最好的方法,可以让你同时做到这两点 . 它允许您将后端拆分为微服务,同时仍为所有应用程序提供单个API,并允许跨不同服务的数据进行连接 .

如果您不想将REST用于您的微服务,您当然可以让每个都有自己的GraphQL API,但您仍然应该有一个API网关 . 人们使用API网关的原因是使从客户端应用程序调用微服务更易于管理,而不是因为它非常适合微服务模式 .

3 years ago

请参阅文章here,其中说明方法#1如何以及为何更好地运作 . 另请参阅我提到的文章中的下图:
enter image description here

将所有内容置于单个 endpoints 后面的主要好处之一是,与每个请求都有自己的服务相比,可以更有效地路由数据 . 虽然这是GraphQL经常被吹捧的 Value ,复杂性和服务蠕变的减少,但由此产生的数据结构也可以非常明确地定义数据所有权,并明确界定 .

采用GraphQL的另一个好处是,您可以从根本上断言对数据加载过程的更大控制 . 由于数据加载器的过程进入其自己的 endpoints ,因此您可以部分地,完全地或通过警告来满足请求,从而以极其精细的方式控制数据的传输方式 .

以下文章很好地解释了这两个好处:https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

3 years ago

对于方法#2,事实上这就是我选择的方式,因为它比手动维护烦人的API网关容易得多 . 通过这种方式,您可以独立开发服务 . 让生活更轻松:P

有一些很好的工具可以将模式组合成一个,例如graphql-weaver和apollo的graphql-tools,我正在使用 graphql-weaver ,它易于使用且效果很好 .

3 years ago

由于微服务架构没有正确的定义,没有特定的这种风格的模型,但是,大多数都没有明显的特征 . 在微服务架构的情况下,每个服务可以分解成单独的小组件,这可以是单独调整和部署,不会影响应用程序的完整性这意味着您只需更改一些服务,而无需通过自定义microservices app development进行应用程序重新部署 .

3 years ago

有关微服务的更多信息,我认为GraphQL在无服务器架构中也可以完美运行 . 我不使用GraphQL,但我有my own similar project . 我将它用作aggregator,它可以调用许多函数并将其集中到单个结果中 . 我认为你可以为GraphQL应用相同的模式 .