何时以及如何将 GraphQL 与微服务架构一起使用 [英] When and How to use GraphQL with microservice architecture

问题描述

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

I'm trying to understand where GraphQL is most suitable to use within a microservice architecture.

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

There is some debate about having only 1 GraphQL schema that works as API Gateway proxying the request to the targeted microservices and coercing their response. Microservices still would use REST / Thrift protocol for communication though.

另一种方法是为每个微服务使用多个 GraphQL 模式.拥有一个较小的 API 网关服务器，将请求路由到目标微服务，其中包含请求的所有信息 + GraphQL 查询.

Another approach is instead to have multiple GraphQL schemas one per microservice. Having a smaller API Gateway server that route the request to the targeted microservice with all the information of the request + the GraphQL query.

第一种方法

将 1 个 GraphQL 模式用作 API 网关会有一个缺点，即每次更改微服务合同输入/输出时，我们都必须在 API 网关端相应地更改 GraphQL 模式.

Having 1 GraphQL Schema as an API Gateway will have a downside where every time you change your microservice contract input/output, we have to change the GraphQL Schema accordingly on the API Gateway Side.

第二种方法

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

If using Multiple GraphQL Schema per microservices, make sense in a way because GraphQL enforces a schema definition, and the consumer will need to respect input/output given from the microservice.

问题

• 您认为 GraphQL 在哪里适合设计微服务架构?

• Where do you find GraphQL the right fit for designing microservice architecture?

您将如何设计具有可能的 GraphQL 实现的 API 网关?

How would you design an API Gateway with a possible GraphQL implementation?

推荐答案

绝对接近 #1.

让您的客户端与多个 GraphQL 服务对话(如方法 #2)完全违背了使用 GraphQL 的初衷，即为您的整个应用程序数据提供一个架构，以允许在单次往返中获取它.

Having your clients talk to multiple GraphQL services (as in approach #2) entirely defeats the purpose of using GraphQL in the first place, which is to provide a schema over your entire application data to allow fetching it in a single roundtrip.

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

Having a shared nothing architecture might seem reasonable from the microservices perspective, but for your client-side code it is an absolute nightmare, because every time you change one of your microservices, you have to update all of your clients. You will definitely regret that.

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

GraphQL and microservices are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into microservices, but from a frontend perspective, you would like all your data to come from a single API. Using GraphQL is the best way I know of that lets you do both. It lets you split up your backend into microservices, while still providing a single API to all your application, and allowing joins across data from different services.

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

If you don't want to use REST for your microservices, you can of course have each of them have its own GraphQL API, but you should still have an API gateway. The reason people use API gateways is to make it more manageable to call microservices from client applications, not because it fits well into the microservices pattern.

这篇关于何时以及如何将 GraphQL 与微服务架构一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！