我的公司运行的微服务架构具有50多个服务，这些服务由单个GraphQL端点提供支持，这些服务可以协调服务之间的调用，为最终用户提供Android和iOS应用程序的支持。
我们正在开发一种新产品，该产品将不会被那些最终用户使用，而是针对那些通过我们的应用程序为我们的最终用户提供商品的公司。 TL; DR：诸如通过我们的平台显示有关其销售的性能数据之类的事情。
由于该新产品和我们的应用程序的数据要求几乎没有不同，因此我们正在讨论仅为此产品创建一个新的GraphQL端点，因为我们担心将原始GraphQL层放在一个整体上，例如，在发生灾难的情况下，它只能作为单点故障。
查看GraphQL的网站，Facebook帖子，Apollo的Principled Graphql等，在某处很容易看到“单个端点”短语。我想知道直到什么时候仍然有效。
任何人的建议/意见，甚至有关此讨论者的推荐都将受到赞赏。如果您的公司之前进行过讨论，那么最终决定是什么？考虑了什么？
答案 0 :(得分：0)
我建议也许以不同的方式考虑问题。
如果我正确理解这一点，那么您正在处理几个问题：
这是一个很好的总结吗？
无论您选择哪种API实现，建议您都应该查看API网关来保护您的外部API。无论如何，您都需要身份验证和授权。
API网关还使您可以控制如何路由API调用。如果您选择对内部和外部使用相同的API，则可以为这些API实现池提供冗余，并且仅允许API网关在这些子集之间进行负载平衡。这意味着即使这些请求完全解决了，您也应该保留一些处理内部请求的能力。 （如果负载实际上是在后端数据源上，那么这完全是另一个问题！）
如果您正在寻找构建完全独立运行但重用功能的单独GraphQL API的方法，则可以考虑使用Apollo之类的方法来做到这一点，但是我不是GraphQL专家。
但是，如上所述，您对单点故障的担忧可能需要考虑您的后端。无论您如何隔离网关，代理，GraphQL端点等，如果它们都命中相同的数据库，那么灾难可能会同时导致内部和外部API中断。
希望能给您带来深思的机会。
答案 1 :(得分：0)
如果您遇到了这个问题，正如我注意到它在Google搜索结果的顶部，我也将此问题作为Github问题发布到了graphql-spec存储库中，并得到了该规范核心维护者的好评。您可能需要检查一下：https://github.com/graphql/graphql-spec/issues/569
我现在将其标记为可接受的答案。