GraphQL和Microservices

Question

在我的公司，我们已经决定了一个新项目的微服务架构。我们已经了解了GraphQL，并认识到它作为单个API端点使用的潜力和优势。

我们不同意的是如何在GraphQL和每个微服务之间进行通信。有些人主张休息，另一些人则认为我们也应该为每个服务设置一个graphQL端点。

我想知道每个人的优点和缺点是什么。例如，使用graphQL中的所有内容似乎有点多余，因为我们将在每个服务中复制模式的部分内容。另一方面，我们使用GraphQL来避免一些REST陷阱。我们担心拥有REST端点会抵消从gQL中获得的优势。

有没有人遇到过类似的困境？我们中没有一个人对GraphQL有经验，所以这里是否有明显的正反之处，我们可能会错过？

提前感谢！

Answer 1

问得好！听起来你在问如何为GraphQL和微服务设置架构，以及为什么。

背景

我建议使用GraphQL，因为它的最佳用例是以一种干净的方式合并数据源，并通过一个标准化的API向您公开所有这些数据。另一方面，使用微服务的主要问题之一是很难对您可能拥有的所有不同功能进行争论。随着应用程序的发展，它将成为整合所有这些微服务功能的一个主要问题。

使用这些技术的好处是巨大的，因为现在您基本上拥有了一个GraphQL API网关，它允许您从客户端访问您的微服务，就好像它是一个单一的应用程序一样，但您也从性能和效率的角度获得了使用微服务的许多好处。

架构

因此，我建议的体系结构是让一个GraphQL代理坐在您的微服务前面，在您的GraphQL查询和突变解析器中，调用所需的函数来检索所需的数据。

在GraphQL微服务前面有一个GraphQL网关或者在REST端点前面有一个GraphQL网关并不那么重要，尽管我实际上认为，将您的微服务函数公开为REST端点会更简单，因为理论上每个函数应该只提供一个用途。在这种情况下，您将不需要GraphQL的额外开销和复杂性，因为在幕后不应该有太多的关系逻辑。

如果您正在寻找微型服务提供商，我看到的最好的供应商是拉姆达、网络任务、Azure函数和Google云功能。您可以使用无服务器作为管理和部署这些微服务功能的方法。

例如，：

import request from 'request';

// GraphQL resolver to get authors
const resolverMap = {
  Query: {
    author(obj, args, context, info) {
      // GET request to fetch authors from my microservice
      return request.get('https://example.com/my-authors-microservice');
    },
  },
};

GraphQL服务

这也是我们在斯卡伯德上一直在探索的，如果您想要依赖服务来帮助您管理这个工作流的话。我们首先提供一个GraphQL后端服务，帮助您在几分钟内开始使用GraphQL，然后允许您将自己的微服务(即自定义逻辑)附加到GraphQL API中，作为函数的组合。它本质上是最先进的web钩子系统，它为您提供灵活性，并控制如何调用您的微服务。

如果您在以下区域，也可以加入SF中的无服务器GraphQL会议 :)

希望这能有所帮助！

Answer 2

我的公司已经在生产中使用GraphQL大约一年了。在我们的"Platform API“中以及在我们的微服务中维护模式变得非常困难。开发人员一直在问我们，为什么他们需要做双倍的工作，好处是什么。特别是因为我们需要深入的代码检查来更改/更新生产GraphQL模式。

阿波罗GraphQL发布了模式拼接，它解决了我们所面临的大部分问题。本质上，每个微服务都维护自己的GraphQL端点，然后我们的Node.js平台API将它们连接在一起。由此产生的API是客户端开发人员的梦想，后端开发人员对他们习惯的代码具有一定程度的自主权。我强烈建议尝试模式拼接。几个月来，我们一直在逐步采用它，这真是太棒了。

作为一个额外的好处，在定义我们的子模式时，我们开始将某些微服务解耦，而依赖于缝合的数据扩展来填补对象中的漏洞。感觉就像DDD中缺失的部分

Answer 3

您正在询问如何在微服务体系结构中使用GraphQL。您正在考虑的一种方法是，所有的微服务都是GraphQL。另一种方法是使用GraphQL作为后端数据API的API网关和REST。

在最近的一个评估中，包括了基于节点的数据API微服务的负载测试，我得出的结论是，Express (REST)比阿波罗(GraphQL)更高效。结果表明，与带有特定手工编码的GraphQL处理程序的JSON解析相比，查询的通用解析和执行成本相对较高。鉴于这一发现，我建议保留数据APIs。