GraphQL 和微服务
GraphQL and Microservices
在我的公司，我们决定为一个新项目采用微服务架构。
我们已经了解了 GraphQL 并意识到它用作我们的单一 API 端点的潜力和优势。
我们不同意的是 GraphQL 和每个微服务之间应该如何进行通信。一些人支持 REST，另一些人则说我们还应该为每个服务提供一个 graphQL 端点。
我想知道每种方法的优缺点是什么。
例如，将所有内容都放在 graphQL 中似乎有点多余，因为我们会在每个服务中复制部分模式。
另一方面，我们使用 GraphQL 来避免一些 REST 陷阱。我们担心拥有 REST 端点会抵消从 gQL 获得的优势。
有没有人遇到过类似的困境？
None 我们中有 GraphQL 经验，那么这里是否有一些我们可能遗漏的明显利弊？
提前致谢！
好问题！听起来您是在问如何为 GraphQL 和微服务设置架构，以及为什么。
背景
我建议使用 GraphQL，因为它的最佳用例是以一种干净的方式整合数据源，并通过一个标准化 API 向您公开所有数据。另一方面，使用微服务的主要问题之一是很难将您可能拥有的所有不同功能都考虑在内。随着您的应用程序的增长，整合所有这些微服务功能成为一个主要问题。
使用这些技术的好处是巨大的，因为现在您基本上拥有一个 GraphQL API 网关，它允许您从客户端访问您的微服务，就好像它是一个单一的整体应用程序一样，但您还可以获得从性能和效率的角度来看使用微服务的许多好处。
建筑
所以我推荐的架构是在你的微服务前面有一个 GraphQL 代理，在你的 GraphQL 查询和突变解析器中，调用你需要检索必要数据的函数。
在 GraphQL 微服务之前使用 GraphQL 网关或在 REST 端点之前使用 GraphQL 网关之间并没有那么重要，尽管我实际上认为将微服务函数公开为更简单REST 端点，因为每个功能理论上应该只服务于一个目的。在这种情况下，您不需要 GraphQL 的额外开销和复杂性，因为幕后不应该有太多的关系逻辑。
如果您正在寻找微服务提供商，我见过的最好的提供商是 AWS Lambda, Webtask, Azure Functions, and Google Cloud Functions. And you can use Serverless 作为管理和部署这些微服务功能的一种方式。
例如：
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 服务
这是我们在 Scaphold 上一直在探索的内容，以防您希望依赖某项服务来帮助您管理此工作流。我们首先提供 GraphQL 后端服务，帮助您在几分钟内开始使用 GraphQL，然后允许您将自己的微服务（即自定义逻辑）作为函数组合附加到您的 GraphQL API。它本质上是最先进的 webhook 系统，让您可以灵活地控制如何调用您的微服务。
如果您在该地区，请随时加入旧金山的 Serverless GraphQL Meetup:)
希望对您有所帮助！
我的公司在生产中使用 GraphQL 已经大约一年了。在我们的 "Platform API" 和我们的微服务中维护模式变得很困难。开发人员一直问我们为什么他们需要做双重工作以及有什么好处。特别是因为我们需要对 change/update 生产 GraphQL 模式
进行深入的代码审查
Apollo GraphQL 发布 schema stitching 解决了我们遇到的大部分问题。本质上，每个微服务都维护自己的 GraphQL 端点，然后我们的 Node.js 平台 API 将它们拼接在一起。由此产生的 API 是客户端开发人员的梦想，后端开发人员获得了他们习惯的代码自主权级别。我强烈建议尝试模式拼接。几个月来我们一直在逐步采用它，效果非常好。
作为一个额外的好处，在定义我们的子模式时，我们开始解耦某些微服务，而不是依靠缝合的数据扩展来填充对象中的漏洞。感觉像是 DDD
中缺失的部分
您问的是如何在微服务架构中使用 GraphQL。您正在考虑的一种方法是所有微服务都是 GraphQL。另一种方法是使用 GraphQL 作为 API 网关，并使用 REST 作为后端数据 API。
在最近的 evaluation 中，其中包括基于节点的数据 API 微服务的负载测试，我得出结论，Express (REST) 比 Apollo (GraphQL) 更高效。事实证明，与 JSON 使用特定的、手工编码的 API 处理程序进行解析相比，GraphQL 查询的通用解析和执行可能相对昂贵。鉴于这一发现，我建议保留数据 APIs RESTful.
在我的公司，我们决定为一个新项目采用微服务架构。 我们已经了解了 GraphQL 并意识到它用作我们的单一 API 端点的潜力和优势。
我们不同意的是 GraphQL 和每个微服务之间应该如何进行通信。一些人支持 REST，另一些人则说我们还应该为每个服务提供一个 graphQL 端点。
我想知道每种方法的优缺点是什么。 例如，将所有内容都放在 graphQL 中似乎有点多余，因为我们会在每个服务中复制部分模式。 另一方面，我们使用 GraphQL 来避免一些 REST 陷阱。我们担心拥有 REST 端点会抵消从 gQL 获得的优势。
有没有人遇到过类似的困境？ None 我们中有 GraphQL 经验，那么这里是否有一些我们可能遗漏的明显利弊？
提前致谢！
好问题！听起来您是在问如何为 GraphQL 和微服务设置架构，以及为什么。
背景
我建议使用 GraphQL，因为它的最佳用例是以一种干净的方式整合数据源，并通过一个标准化 API 向您公开所有数据。另一方面，使用微服务的主要问题之一是很难将您可能拥有的所有不同功能都考虑在内。随着您的应用程序的增长，整合所有这些微服务功能成为一个主要问题。
使用这些技术的好处是巨大的，因为现在您基本上拥有一个 GraphQL API 网关，它允许您从客户端访问您的微服务，就好像它是一个单一的整体应用程序一样，但您还可以获得从性能和效率的角度来看使用微服务的许多好处。
建筑
所以我推荐的架构是在你的微服务前面有一个 GraphQL 代理，在你的 GraphQL 查询和突变解析器中，调用你需要检索必要数据的函数。
在 GraphQL 微服务之前使用 GraphQL 网关或在 REST 端点之前使用 GraphQL 网关之间并没有那么重要，尽管我实际上认为将微服务函数公开为更简单REST 端点，因为每个功能理论上应该只服务于一个目的。在这种情况下，您不需要 GraphQL 的额外开销和复杂性，因为幕后不应该有太多的关系逻辑。
如果您正在寻找微服务提供商，我见过的最好的提供商是 AWS Lambda, Webtask, Azure Functions, and Google Cloud Functions. And you can use Serverless 作为管理和部署这些微服务功能的一种方式。
例如：
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 服务
这是我们在 Scaphold 上一直在探索的内容，以防您希望依赖某项服务来帮助您管理此工作流。我们首先提供 GraphQL 后端服务，帮助您在几分钟内开始使用 GraphQL，然后允许您将自己的微服务（即自定义逻辑）作为函数组合附加到您的 GraphQL API。它本质上是最先进的 webhook 系统，让您可以灵活地控制如何调用您的微服务。
如果您在该地区，请随时加入旧金山的 Serverless GraphQL Meetup:)
希望对您有所帮助！
我的公司在生产中使用 GraphQL 已经大约一年了。在我们的 "Platform API" 和我们的微服务中维护模式变得很困难。开发人员一直问我们为什么他们需要做双重工作以及有什么好处。特别是因为我们需要对 change/update 生产 GraphQL 模式
进行深入的代码审查Apollo GraphQL 发布 schema stitching 解决了我们遇到的大部分问题。本质上，每个微服务都维护自己的 GraphQL 端点，然后我们的 Node.js 平台 API 将它们拼接在一起。由此产生的 API 是客户端开发人员的梦想，后端开发人员获得了他们习惯的代码自主权级别。我强烈建议尝试模式拼接。几个月来我们一直在逐步采用它，效果非常好。
作为一个额外的好处，在定义我们的子模式时，我们开始解耦某些微服务，而不是依靠缝合的数据扩展来填充对象中的漏洞。感觉像是 DDD
中缺失的部分您问的是如何在微服务架构中使用 GraphQL。您正在考虑的一种方法是所有微服务都是 GraphQL。另一种方法是使用 GraphQL 作为 API 网关，并使用 REST 作为后端数据 API。
在最近的 evaluation 中，其中包括基于节点的数据 API 微服务的负载测试，我得出结论，Express (REST) 比 Apollo (GraphQL) 更高效。事实证明，与 JSON 使用特定的、手工编码的 API 处理程序进行解析相比，GraphQL 查询的通用解析和执行可能相对昂贵。鉴于这一发现，我建议保留数据 APIs RESTful.