我试图理解GraphQL在微服务架构中最适合使用的地方。
对于只有一个GraphQL模式作为API网关代理请求到目标微服务并强制它们的响应,存在一些争论。微服务仍然使用REST / Thrift协议进行通信。
另一种方法是使用多个GraphQL模式,每个微服务一个。使用一个较小的API Gateway服务器,将请求路由到目标微服务,并将请求的所有信息+ GraphQL查询。
1号的方法
使用一个GraphQL模式作为API网关会有一个缺点,每次你改变你的微服务契约输入/输出时,我们必须在API网关端相应地改变GraphQL模式。
2方法
如果每个微服务都使用多个GraphQL模式,在某种程度上是有意义的,因为GraphQL强制了一个模式定义,消费者需要尊重微服务给出的输入/输出。
问题
你在哪里发现GraphQL适合设计微服务架构?
你将如何设计一个具有GraphQL实现的API网关?
绝对接近第一条。
让您的客户机与多个GraphQL服务通信(如方法#2所示)完全违背了使用GraphQL的初衷,GraphQL的目的是在整个应用程序数据上提供一个模式,以允许在一次往返中获取数据。
从微服务的角度来看,无共享架构似乎是合理的,但对于客户端代码来说,这绝对是一场噩梦,因为每次你改变一个微服务时,你都必须更新所有的客户端。你一定会后悔的。
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网关的原因是为了使从客户端应用程序调用微服务更易于管理,而不是因为它很适合微服务模式。
在使用graphql引导微服务生态系统时,我们也有类似的担忧。我们可以用Apollo GraphQL解决这个问题。
我们为“一个平台”从零开始构建了这些解决方案。以service结尾的文件夹是微服务,其他的是spa(单页应用程序)
它由各种微服务和带有API网关的spa组成,API网关是多个微服务的主要接口。
与此同时,你可以找到一个OP CLI生成器,它可以帮助你从零开始引导微服务。
项目- https://github.com/1-Platform/one-platform
我请求请看看这个项目,并随时采取,如果这看起来对你很好。
问候
Rigin Oommen