应用程序中的 GraphQL：成本、价格和采用前的清单

[GraphQL0 作为一个诱人的承诺进入产品词汇：客户在一次请求中仅要求他们所需的数据，仅此而已。对于移动应用程序来说，每个字节和每次网络往返都很重要，这听起来像是完美的解决方案。在很多情况下确实如此。

问题在于，关于 [GraphQL1] 的讨论几乎总是忽略成本列。详细讨论了承诺；价格，很少。 GraphQL 的价格不在于许可证，它是开源的，而在于复杂性、基础设施和团队时间。这些成本是真实的，决定了采用是否值得还是会后悔。

本文是为任何即将决定在应用程序中采用 [GraphQL2´ 的人提供的清单。在迁移之前，请先检查以下几点。他们将成熟的决策与昂贵的炒作区分开来。

为什么 GraphQL 的成本一开始是看不见的

[GraphQL3 不收取许可费用，因此感觉是免费的。这就是陷阱。成本后来出现，分布在最初决策没有考虑到的地方：团队学习的时间、变得更加复杂的缓存基础设施、监控和保护查询的工作可能变得繁重。

与 SaaS 订阅不同，此费用不会出现在发票上。它的表现是一开始的交付速度较慢、性能错误、工程时间长。这就是为什么它会从电子表格中消失，这就是为什么下面的清单如此重要。

采用清单

在下面签名之前，请诚实回答每一项。

您遇到的问题实际上是 GraphQL 问题吗？

当应用程序消耗来自多个来源的数据时，当不同的屏幕需要相同数据的不同组合时，或者当 [REST API4] 的过度获取对移动网络造成压力时，GraphQL 就会发挥作用。如果您的应用程序几乎没有稳定且设计良好的端点，那么 GraphQL 可能是您没有的问题的解决方案。成本无回报。

团队有学习能力吗？

[GraphQL5带来了新概念：模式、解析器、N+1 查询问题、与 REST 不同的缓存。学习成本是真实的，而且曲线也不是微不足道的。如果团队规模小且超负荷，这笔成本可能会导致交付延迟数月。将学习曲线包含在账单中，它是价格的一部分。

您准备好承担服务器性能成本了吗？

GraphQL在客户端上的灵活性在服务器上变得复杂。一个写得不好的查询可能会触发数十个数据库查询，这是经典的 N+1 问题。解决这个问题需要 DataLoader 等工具和解析器规则。如果没有这个，GraphQL 会让你的后端变慢，而不是更快。这是经常性的工程成本。

缓存怎么样？

在 REST 中，HTTP 缓存成熟且廉价，CDN 本身就理解 REST。在 [GraphQL7 中，由于所有内容都通过 POST 通过单个端点，因此传统缓存的工作方式不同。您需要在客户端级别（Apollo 客户端、中继）进行缓存，有时还需要服务器上的特定解决方案。这是 REST 不收取的基础设施和复杂性成本。

你能保护端点吗？

GraphQL 的灵活性也是一个攻击面。深度嵌套查询可导致服务器超载。您需要特定的深度、复杂性和速率限制。在 [LGPD8] 的背景下，还必须注意确保控制不善的模式不会暴露应受保护的个人数据。安全性是清单上的强制性项目，而不是可选项目。

如何为决策定价

添加清单成本：团队学习时间、缓存和保护实施工作、额外的操作复杂性。比较收益：移动带宽节省、前端敏捷性、更少的 API 版本控制。

如果您的应用程序确实遭受过度获取和多个数据源的困扰，那么收益大于成本，并且 [GraphQL9] 会收回成本。如果您的数据消耗简单且稳定，则成本大于收益，而精心设计的 REST 可以以一小部分价格提供几乎相同的价值。

成熟的决定不是“[GraphQL10更好”。它是“GraphQL 解决了我遇到的问题，并且我愿意为此付出代价。”

采用过程中最常见的错误

经常出现的错误是采用[GraphQL11]是出于时尚，而不是出于必要。团队迁移是因为它很流行，付出了复杂性的所有成本，并发现以前的 REST 很好地解决了他们需要的东西。费用已支付；问题并不存在。

第二个错误是低估了持续的运营成本。 [GraphQL12 并不是“设置好后就忘记它”。它需要持续的查询性能监控、模式管理和对安全性的关注。任何在没有预见到这种经常性成本的情况下采用的人最终都会得到一个脆弱且昂贵的后端来维护。

您预测过版本控制和演进的成本吗？

支持 [GraphQL13 的一个强有力的论据是它减少了 API 版本控制的痛苦。在 REST 中，更改通常需要新的端点版本，而商店中的移动应用程序会与旧版本一起使用数月。 GraphQL 允许您通过添加字段来发展架构，而不会破坏现有客户。

这是一个真正的好处，值得作为贷方（而不仅仅是借方）包含在清单中。对于无法控制用户更新时间的移动应用程序，这种在不破坏旧版本的情况下发展的能力具有具体的商业价值：减少强制更新，减少对多个 API 版本的支持。

但存在内在的纪律成本。已弃用的字段需要一种删除策略，否则架构会因无人敢删除的遗留而膨胀，同样的债务问题也会影响[功能标志14。如果没有模式治理，演化的好处就会变成维护的负担。因此，清单项不仅仅是“GraphQL 版本更好”，而是“我有一个流程来管理模式随时间的演变”。

重要的决定

[GraphQL15 对于正确的问题来说是一个出色的工具，对于错误的问题来说则是不必要的成本。上面的清单可以让您在付款之前（而不是之后）了解自己属于哪种情况。

如果问题确实存在，如果团队有能力应对这种情况，并且您已准备好承担缓存和安全性的成本，则采用。否则，做得好的 REST 更便宜且足够。成熟在于根据需要进行选择，而不是根据标题进行选择。

如果您正在评估您的应用程序的 [GraphQL16 并希望仔细检查适用于您的案例的清单，那么它值得讨论。博客上还有另一篇关于 GraphQL 的文章，其中包含具体场景中的成本示例，以及有关 API 架构和移动后端的文本。

另请阅读

• [GraphQL的应用：通过具体例子说明成本和价格17
• [GraphQL 应用程序：实施指南18
• [应用后端：架构、技术和最佳实践19
• [应用中的微服务：移动分布式架构20
• [应用程序后端 - 扩展的良好实践21
• [应用程序后端 - 初创公司的良好实践22