GraphQL的甜蜜点

如今，GraphQL无处不在。从Facebook最初对GraphQL的使用，到一些更时髦的用途，比如数据库，GraphQL受到了如此多的开发人员的喜爱，以至于我们开始在最初没有人会想到的领域使用GraphQL。

每种技术都有它理想的用例，它可以工作的用例，它完全不适合的用例，以及介于两者之间的所有用例。作为开发人员，我们希望为这项工作选择合适的工具，这意味着了解我们的用例，并考虑哪些技术可能最适合它。这包括技术本身的特性，但也包括我们对它的熟悉程度、它周围的社区等等。

最近，我花了一些时间思考GraphQL最闪亮的地方。我们可以称它为“图形甜蜜点”。

任何接近中间的东西都是我认为GraphQL最合适的地方。至于圈子的外部，我认为GraphQL可以使用，但也许它并没有从同样的优势中受益。也许我们可以把它看作是不同的层次。

在我们探讨这些层次之前，让我先说清楚一点：即使GraphQL的某些用法超出了所谓的“甜蜜点”，也不意味着它们是完全无效的，它主要意味着您可能会得到更少的好处，或者必须投资更多的工具来使其更合适。这也可能意味着我刚刚落后于时代；)。

GraphQL的第一层使用案例是将其用作支持多个客户端的内部API。这是Facebook最初的用例，我们可以预期GraphQL会针对它进行优化。那么，那个用例到底是什么呢？

我们对我们希望在应用程序中使用的数据与它们所需的服务器查询之间的差异感到沮丧。[来源]。

在GraphQL之前，丹尼尔·雅各布森(Daniel Jacobson)也强调了类似的担忧。丹尼尔的文章仍然是我最喜欢的一些文章：

RESTAPI非常擅长以通用方式处理请求，它建立了一组规则，允许大量已知和未知的开发人员轻松使用API提供的服务。

在这个模式中，每个人都知道如何行事，它可以是令人难以置信的强大。API提供者建立了一组规则，API使用者必须遵守这些规则才能从API获得他们想要的东西。太完美了，对吧？在许多情况下，答案显然是肯定的。但在其他情况下，随着我们的世界规模扩大，人们消费数字内容和服务的方式数量继续扩大，这种一刀切的模式可能会达不到要求。[来源]。

在这两种情况下，GraphQL都可以被视为解决API提供者和客户成长烦恼的一种解决方案，因为当用例由一刀切的API提供支持，并试图被SSKD(用Daniel的话说，是为数不多的已知开发人员)所使用时，GraphQL可以被视为一种解决方案。

GraphQL允许不同的客户端以不同的方式使用服务器的可能性，将服务器模式与客户端使用它的方式解耦。对我来说，这是你想要考虑选择GraphQL的主要原因。

这意味着您在使用“一刀切”的API时确实有些困难。你可能不会。例如，如果您的API主要公开公共的、未经验证的静态数据，那么客户端的灵活性可能不值得失去网络缓存，也可能不需要GraphQL执行引擎的开销。

如果我们处理具有易失性数据的经过身份验证的API，并且多个设备/客户端/UI以不同的方式使用它，我认为GraphQL是在公司规模上解决OSFA问题的一种很好的方法。让我们移到第二层去吧。

第二层是认为GraphQL非常合理和良好的用法，但可能不是出于非常特定于GraphQL的原因。

第一个示例是单个前端客户端通过API与GraphQL对话。如今，JAMStack风格的应用程序更加流行。

对于单个客户端，不存在临时端点和管理特定于客户端的服务器端资源的问题。这些应用程序喜欢GraphQL，因为它不一定是独一无二的或与生俱来的东西：

这些都是伟大的东西。我之所以将此使用上下文包括在第二层而不是第一层，是因为在单个客户端用例中，可能需要也可能不需要完整GraphQL平台的开销。

我们上面列出的东西也不需要专门来自GraphQL。许多其他API样式允许您使用模式或API描述，其中一些风格有很好的工具，在设计API时，倾听客户端用例应该始终是最重要的。

尽管如此，GraphQL仍然是一个很好的选择，因为它确实将许多这些优点结合在一起，成为一个伟大的、即用即用的软件包，并且所有这些都是明确规定的。与其他需要开发人员选择最佳工具、规范和最佳实践的API样式相比，正确使用GraphQL要容易得多。现在只有一个客户端并不意味着你以后不会遇到与支持多个内部客户端相关的问题，这将使采用GraphQL成为一种面向未来的好方法(不过，很难提前知道这些事情)。

我认为属于第二层的另一个用例是公共GraphQL API。同样用Daniel Jacobson的话说，就是处理LSUD(大量未知开发人员)的API。一方面，GraphQL似乎非常适合这个用例。它使得处理大量不同的客户端用例比必须为所有这些用例构建定制资源或定制RPC调用要容易得多。事实上，我们可以将其视为允许任何客户端基于模式创建自己的服务器端资源。另一方面，当GraphQL在考虑到特定客户的情况下定义其可能性时，它会大放异彩。许多公共API必须保持更通用的东西，以允许这么多未知的客户端找到他们需要的东西，并发明我们从一开始就没有想到的东西。

要使第三方开发人员能够构建有趣的集成，您需要设计一个API，该API不需要假设数据将如何使用。来源。

虽然这无论如何都不会使GraphQL成为公共API的坏选择，但它确实意味着它迫使服务器以更通用的方式公开用例，这是GraphQL API在内部场景中通常试图避免的。话虽如此，到最后，正如我最近在推特上写的那样，如果客户喜欢处理GraphQL并要求第三方提供商提供它，那么GraphQL是否是完美的公共API可能甚至无关紧要。

第二层是目前我们看到的GraphQL实现数量最多的地方。很可能是因为第一级环境是在项目/公司生命周期较晚的时候出现的问题。

第三层用于有趣的用例，但我发现GraphQL与其他现有选项相比几乎没有优势。

其中之一是服务到服务的通信。正如我在#34；中提到的，GraphQL是东西服务通信的最佳选择吗？"；，服务调用通常需要针对单个用例进行充分优化，而查询引擎的开销很少是值得的。当像GRPC、Twirp和Thrift这样的工具存在时，在我看来，您需要一个非常好的理由不使用这些经过验证的工具，而使用GraphQL。

另一种是直接与数据库交互。开发人员喜欢GraphQL查询语言，但它从来没有打算成为一种通用的、功能强大的数据库查询语言。似乎很难为它辩护，而且它越来越受欢迎，开发人员也越来越熟悉它。

同样，这并不意味着这些用例是完全无效的。即使在第三层，我们也可以明确决定使用GraphQL。这样做的好例子可能是一致性(已在其他领域使用GraphQL)、内部专业知识(团队是GraphQL方面的专家)，甚至是开发人员的幸福感。这些东西更难衡量，而且在很大程度上取决于特定的场景。

那么，这一切的意义是什么呢？我认为我们的问题离GraphQL甜蜜点越远，我们就越需要思考为什么我们要选择它作为我们的选择工具。GraphQL虽然是一个非常强大的想法，但也带来了一些复杂性。理想情况下，我们希望这种复杂性成为我们明确做出的权衡，因为我们知道GraphQL以一种很好的方式解决了手头的问题。

然而，令人惊讶的是，由于GraphQL作为单一规范带来了如此多的优势，它对许多人来说是一个有吸引力的选择，尽管有时并不需要它的核心属性。这是许多生态系统和社区可以学习的东西。

如果你喜欢这篇文章，你可能会喜欢我刚刚发布的生产准备好的GraphQL书！