我试图理解GraphQL在微服务架构中最适合使用的地方。
对于只有一个GraphQL模式作为API网关代理请求到目标微服务并强制它们的响应,存在一些争论。微服务仍然使用REST / Thrift协议进行通信。
另一种方法是使用多个GraphQL模式,每个微服务一个。使用一个较小的API Gateway服务器,将请求路由到目标微服务,并将请求的所有信息+ GraphQL查询。
1号的方法
使用一个GraphQL模式作为API网关会有一个缺点,每次你改变你的微服务契约输入/输出时,我们必须在API网关端相应地改变GraphQL模式。
2方法
如果每个微服务都使用多个GraphQL模式,在某种程度上是有意义的,因为GraphQL强制了一个模式定义,消费者需要尊重微服务给出的输入/输出。
问题
你在哪里发现GraphQL适合设计微服务架构?
你将如何设计一个具有GraphQL实现的API网关?
对于问题1,Intuit在几年前宣布迁移到One Intuit API生态系统(https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations-quickbooks-connect-2017)时承认了GraphQL的强大功能。Intuit选择了方法1。您提到的缺点实际上阻止了开发人员引入可能破坏客户端应用程序的破坏性模式更改。
GraphQL在许多方面帮助提高了开发人员的工作效率。
When designing a new microservice for a domain, engineers (backend/ frontend/ stakeholders) agree on a schema for the domain entities. Once the schema is approved, it is merged with the master domain schema (universal) and deployed on the Gateway.Front end engineers can start coding client applications with this schema while backend engineers implement the functionality. Having one universal schema means that there are no two microservices with redundant functionality.
GraphQL has helped client applications become simpler and faster. Want to retrieve data from /update data to multiple microservices? All client applications have to do is fire ONE GraphQL request and the API Gateway abstraction layer will take care to fetch and collate data from multiple sources (microservices). Open source frameworks like Apollo (https://www.apollographql.com/) have accelerated the pace of GraphQL adoption.
With mobile being the first choice for modern applications, it is important to design for lower data bandwidth requirements from ground zero. GraphQL helps by allowing client apps to request for specific fields only.
问题2:我们在API Gateway上构建了一个自定义抽象层,它知道模式的哪一部分属于哪个服务(提供者)。当查询请求到达时,抽象层将请求转发给适当的服务。一旦基础服务返回响应,抽象层就负责返回所请求的字段。
然而,现在有几个平台(Apollo服务器、GraphQL -yoga等)允许人们在短时间内构建一个GraphQL抽象层。
在使用graphql引导微服务生态系统时,我们也有类似的担忧。我们可以用Apollo GraphQL解决这个问题。
我们为“一个平台”从零开始构建了这些解决方案。以service结尾的文件夹是微服务,其他的是spa(单页应用程序)
它由各种微服务和带有API网关的spa组成,API网关是多个微服务的主要接口。
与此同时,你可以找到一个OP CLI生成器,它可以帮助你从零开始引导微服务。
项目- https://github.com/1-Platform/one-platform
我请求请看看这个项目,并随时采取,如果这看起来对你很好。
问候
Rigin Oommen
绝对接近第一条。
让您的客户机与多个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网关的原因是为了使从客户端应用程序调用微服务更易于管理,而不是因为它很适合微服务模式。