GraphQL和微服务架构 [英] GraphQL and Microservice Architecture

问题描述

我试图了解GraphQL在微服务体系结构中最适合使用的地方.

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

关于仅使用1个作为API网关将请求代理到目标微服务并强制其响应的GraphQL模式，存在一些争论.微服务仍会使用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 thought.

另一种方法是每个微服务具有多个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适合设计微服务架构?

• Whether 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屋！