GraphQL和微服务

Question

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

有人遇到过类似的困境吗？我们都没有使用GraphQL的经验，所以这里是否有一些明显的利弊我们可能会遗漏？

提前道谢！

Answer 1

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

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

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

因此，我推荐的架构是在微服务前面设置一个GraphQL代理，并在GraphQL查询和变异解析器中调用检索必要数据所需的函数。

在GraphQL微服务前面有一个GraphQL网关，还是在RESTendpoint前面有一个GraphQL网关，其实并不重要，尽管我实际上认为，将微服务功能公开为RESTendpoint会更简单，因为每个功能理论上应该只为一个目的服务。在这种情况下，您不需要额外的开销和GraphQL的复杂性，因为在后台不应该有太多的关系逻辑。

如果您正在寻找微服务提供商，我见过的最好的是AWS Lambda、Webtask、Azure函数和Google Cloud函数。并且您可以使用无服务器作为管理和部署这些微服务功能的一种方式。

例如：

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');
    },
  },
};

这也是我们在Scaphold一直在探索的东西，以防您希望依赖服务来帮助您管理此工作流。我们首先提供一个GraphQL后端服务，帮助您在几分钟内开始使用GraphQL，然后允许您将自己的微服务（即自定义逻辑）作为函数组合添加到GraphQL API中。它本质上是最先进的webhook系统，它为您提供了如何调用微服务的灵活性和控制。

如果您在以下地区，也可以加入SF中的无服务器GraphQL Meetup：）

希望这有帮助！