我想了解GraphQL最适合在微服务体系结构中使用的位置。GraphQL和微服务体系结构
关于只有1个GraphQL模式作为API网关代理到目标微服务的请求并强制响应，存在一些争议。微服务仍然会使用REST/Thrift协议来进行通信思想。
另一种方法是每个微服务都有多个GraphQL模式。拥有一个较小的API网关服务器，可将请求路由到目标微服务，并提供请求的所有信息+ GraphQL查询。
1日法
有1 GraphQL模式为API网关会在那里每次你改变你的微服务合同的输入/输出一个缺点，我们必须相应地改变GraphQL架构上API网关侧。
第二个方法
如果使用每个微服务多GraphQL架构，有意义的方式，因为GraphQL强制执行模式定义，而消费者将需要尊重从微服务给定的输入/输出。
问题
你在哪里找到GraphQL正确的适合设计微服务架构？
您将如何设计一个可能的GraphQL实现的API网关？
绝对方法＃1。
让您的客户与多个GraphQL服务对话（如方法＃2）完全违背了首先使用GraphQL的目的，即在您的应用程序数据上提供一个架构，以允许在单程往返。
有一个无共享架构似乎从微服务的角度合理，但对于你的客户端代码这是一个绝对的噩梦，因为每次你改变你的微服务的一个时间，你必须更新的所有你的客户。你一定会后悔的。
GraphQL和微服务是一个完美的选择，因为GraphQL隐藏了一个事实，即您拥有来自客户端的微服务架构。从后端角度来看，您希望将所有内容分解为微服务，但从前端角度来看，您希望所有数据都来自单个API。使用GraphQL是我知道的最好的方式，可以让你同时做到这一点。它可以让你将后端分成微服务，同时还为所有应用程序提供单一的API，并允许跨不同服务的数据进行连接。
如果你不想为你的微服务使用REST，你当然可以让它们每个都有自己的GraphQL API，但是你仍然应该有一个API网关。人们使用API网关的原因是为了更方便地从客户端应用程序调用微服务，而不是因为它适合微服务模式。
有关微服务的更多信息，我认为GraphQL也可以在无服务器体系结构中完美工作。我不使用GraphQL，但我有my own similar project。我将它用作aggregator，它调用并将许多函数集中到单个结果中。我认为你可以对GraphQL应用相同的模式。
对于方法＃2，实际上这是我选择的方式，因为它比手动维护恼人的API网关要容易得多。通过这种方式，您可以独立开发您的服务。让生活变得更容易：P
有一些很好的工具可以将模式合并为一个模板，例如graphql-weaver和apollo的graphql-tools，我使用的是graphql-weaver，它很容易使用，效果很好。
由于微服务架构没有合适的定义，因此没有针对这种风格的特定模型，但其中大多数模型将具有几个显着特征。在微服务架构的情况下，每个服务可以分解为单个小组件，可以单独进行调整和部署，而不会影响应用程序的完整性。这意味着您只需更改一些服务，而无需通过自定义microservices app development进行应用程序重新部署。
请参阅文章here，其中说明了方法＃1如何以及为什么更好地工作。请参阅本文采取下面的图片： 
下面的文章也值得一提：https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/
+1我应该把我的后一个声明，我没有与GraphQL经验，而不是响应基于在回答这个问题的研究过程中阅读一小段简短的内容。我认为这个答案更好地解决了OP的查询。 –
@helfer：这真的很有意义:)谢谢。我在这个美妙的答案之上有几个问题。 - 您是说GraphQL必须用作API网关？ - 假设我有一个** Order ** Microservice，它暴露了REST或GraphQL端点。一旦我完成它，我不得不更新主要GraphQL模式以反映与微服务将暴露的完全相同的数据？它是不是听起来不重复，或者离开应该独立部署的微服务文化？对微服务的任何更改都必须反映/复制到主GraphQL架构？ – Fabrizio
@Fabrizio GraphQL的好处在于即使后端REST API发生变化，只要有一种方法可以获取REST服务先前公开的数据，GraphQL模式仍然可以保持不变。如果它暴露更多的数据，那么处理这个问题的规范方法就是将新的字段/类型添加到现有的模式中。 Facebook创建GraphQL的人告诉我，他们在四年内从未对他们的模式做过任何改变。他们所做的所有更改都是附加的，这意味着新客户可以使用新功能，而老客户可以继续工作。 – helfer