GraphQL和微服务架构
我试图了解GraphQL最适合在微服务体系结构中使用的地方。
关于只有1个作为API网关的GraphQL模式将请求代理到目标微服务并强制响应，存在一些争议。 微服务仍然会使用REST / Thrift协议来进行通信思想。
另一种方法是每个微服务有多个GraphQL模式。 拥有一个较小的API网关服务器，将请求路由到目标微服务，包含请求的所有信息+ GraphQL查询。
第一种方法
如果将1个GraphQL模式作为API网关，则每当您更改微服务合约input/输出时都会有一个缺点，因此我们必须在API网关端相应地更改GraphQL模式。
第二种方法
如果每个微服务使用多个GraphQL模式，那么在某种意义上说是有道理的，因为GraphQL会强制执行一个模式定义，并且消费者需要尊重微服务给出的input/输出。
问题
-
你在哪里发现GraphQL适合devise微服务架构？
-
你将如何devise一个可能的GraphQL实现的API网关？
绝对的方法＃1。
让客户与多个GraphQL服务交谈（如方法2）完全违背了使用GraphQL的目的，即在整个应用程序数据上提供一个模式，以允许在一次往返中获取。
从微服务的angular度来看，拥有一个无共享体系结构似乎是合理的，但是对于客户端代码来说，这绝对是一个噩梦，因为每次更改一个微服务时，都必须更新所有客户端。 你一定会后悔的。
GraphQL和微服务是非常合适的，因为GraphQL隐藏了客户端拥有微服务架构的事实。 从后端的angular度来看，你想把所有的东西都分解成微服务，但是从前端的angular度来看，你希望所有的数据都来自单一的API。 使用GraphQL是我所知道的最好的方式，可以让你同时执行这两个操作。 它可以让你把你的后端分成微服务，同时还为你的应用程序提供一个单一的API，并允许跨不同服务的数据join。
如果你不想为你的微服务使用REST，你当然可以拥有自己的GraphQL API，但是你仍然应该有一个API网关。 人们使用API网关的原因是为了更方便地从客户端应用程序调用微服务，而不是因为它适合微服务模式。
对于方法＃2，实际上这就是我现在所做的，因为它比手动维护API网关更容易。 通过这种方式，您可以独立开发您的服务。 让生活更轻松：P
有一些很好的工具可以将模式合并到一个模块中，例如graphql-weaver和apollo的graphql-tools ，我使用的是graphql-weaver ，它很容易使用，效果很好。
有关微服务的更多信息，我认为GraphQL也可以在无服务器体系结构中工作。 我不使用GraphQL，但我有我自己的类似项目 。 我用它作为一个聚合器 ，调用和集中许多function到单一的结果。 我想你可以对GraphQL应用相同的模式。
