我应该有多个 GraphQL 实例还是只有一个？

Question

我的公司运行一个微服务架构，其中包含 50 多个服务，这些服务由单个 GraphQL 端点提供支持，这些服务协调我们的服务之间的调用，为我们的最终用户提供支持我们的 Android 和 iOS 应用程序。

我们正在开发一种新产品，该产品不会被这些最终用户使用，而是为那些通过我们的应用为最终用户提供商品的公司使用。 TL;DR：例如通过我们的平台显示有关他们的销售业绩数据。

由于这个新产品和我们的应用程序的数据需求几乎没有什么不同，我们正在讨论为这个产品创建一个新的 GraphQL 端点，因为我们害怕将原始 GraphQL 层变成一个整体例如，在发生灾难时表现为单点故障。

查看 GraphQL 的网站、Facebook 帖子、Apollo 的 Principled Graphql 等，很容易在某处看到“单端点”短语。我想知道这仍然有效。

感谢任何人的推荐/意见，甚至是对参与此讨论的人的推荐。如果贵公司之前有过这样的讨论，最终做出的决定是什么，考虑了什么？

Answer 1

我建议也许换个角度思考这个问题。

如果我理解正确的话，您会遇到几个问题：

• 您即将首次向外部各方公开内部 API（或与内部 API 接近的东西）
• 您担心一个对另一个的影响（例如 DDoS 对外部造成您的内部流程停止）
• 您不确定如何最好地构建 GraphQL，以便在相关但可能不同的 API 之间共享相似的功能

这是一个很好的总结吗？

我建议您使用 API 网关来保护您的外部 API，无论您选择什么 API 实现。无论如何，您都需要身份验证和授权。

API 网关还让您可以控制如何路由 API 调用。如果您选择为内部和外部提供相同的 API，则可以拥有这些 API 实现的池以实现冗余，并且只允许 API 网关在其中的一个子集之间进行负载平衡。这意味着即使它们完全耗尽，您也应该有一些保留的容量来处理内部请求。 （如果负载实际上是在您的后端数据源上，那么这完全是另一个问题！）

如果您正在寻找构建完全独立运行但重复使用功能的独立 GraphQL API 的方法，您可以查看 Apollo 之类的方法来执行此操作，但我不是 GraphQL 专家。

不过，正如我上面提到的，您对单点故障的担忧可能需要考虑您的后端。无论您如何隔离网关、代理、GraphQL 端点等，如果它们都访问同一个数据库，那么灾难可能会同时破坏您的内部和外部 API。

希望能让你深思。

Answer 2

如果您遇到这个问题，我注意到它在 Google 搜索结果的顶部，我还在 graphql-spec 存储库上发布了这个问题作为 Github 问题，并从规范的核心维护者那里得到了一些很好的回应。你可以去看看：https://github.com/graphql/graphql-spec/issues/569

我暂时将此标记为已接受的答案。