应用程序中的 GraphQL：通过具体示例说明成本和定价

抽象地讨论 [GraphQL0 会得出无用的结论。 “它更有效率，”爱好者说。 “这更复杂，”怀疑论者回应道。他们都是对的，这就是为什么讨论没有继续进行的原因。 GraphQL 的成本并不是一个固定的属性，它完全取决于应用程序的类型、数据量和团队的成熟度。

了解这些成本的唯一诚实方法是查看具体场景。 [GraphQL1 到底保存在哪里？确切地说，它在哪里收取 REST 不会收取的费用？这在最终的账单中占了多少比重？

本文将介绍三个现实世界的应用场景，以展示 [GraphQL2â 成本方程如何根据具体情况发生变化。这不是理论，而是你所认识的情况下的价格剖析。

场景 1：社交提要应用程序，GraphQL 保存在其中

想象一个社交媒体应用程序，其提要显示每个帖子的作者、照片、评论、点赞数以及当前用户是否喜欢它。在传统的 REST API 中，设置这样的屏幕通常需要多次调用：一个用于帖子，另一个用于作者，另一个用于评论。

在不稳定的移动网络中，每次额外的往返都是用户感受到的延迟。由于 REST 端点返回整个对象，因此应用程序会下载它甚至不使用的字段，过度获取会消耗用户数据计划的带宽。

[GraphQL4 在这里确实省钱了。单个查询在一个请求中准确地从所有实体中获取屏幕所需的字段。带宽和延迟的增益是有形的，移动体验也明显改善。在这里，GraphQL 的复杂性成本是值得的，因为它解决的问题，过度获取和多次调用，正是应用程序的痛苦。

在这种情况下付出的代价是初始学习曲线和解析器的组装。但随着收益不断重复，随着每个用户的 Feed 上传，投资很快就会得到回报。

现在考虑一个用于记录城市清洁事件的内部市政厅应用程序。简单的屏幕、少量的数据类型、直接的流程：列出发生的事件、查看详细信息、创建新的事件。每个屏幕消耗的内容几乎没有变化。

在这里采用 [GraphQL5 付出了很多代价却毫无结果。该应用程序不会遭受严重的过度获取或多个数据源的影响。具有六个端点的 REST 可以通过简单性、本机 HTTP 缓存以及对任何开发人员来说几乎为零的学习曲线来实现这一点。

这里 GraphQL 的成本是纯粹的重量：团队需要学习模式和解析器，处理不像 REST 那样工作的缓存，并保护不需要灵活的灵活端点。所有这一切都是为了一个数据复杂性不合理的产品。这是付出代价却没有得到好处的典型例子。

该场景的教训是：[GraphQL7一点也好不到哪儿去。对于简单稳定的数据应用来说，这是一笔没有回报的额外费用。

考虑一个电子商务应用程序，它在正确的阶段采用了 [GraphQL8，但增长很快。以前的轻量级查询现在涵盖目录、库存、个性化定价和推荐。客户端打开主页并触发查询，该查询在服务器上会变成对银行的数十个查询，这是典型的 N+1 问题。

[GraphQL9 的隐性成本以基础设施账单和性能事件的形式出现。对客户端来说看似有效的事情变成了对后端的压力。解决问题需要投资 DataLoader 来对查询进行分组、监控查询复杂性和深度限制，而这项工程成本并不包含在最初的账单中。

随着规模的扩大，安全成本也会增加。没有限制的公开 GraphQL 端点可用于故意进行大量查询，从而导致服务器瘫痪。而且，在 [LGPD10] 的背景下，未经治理而增长的模式最终可能会通过嵌套路径提供对应受到限制的个人数据的访问。审核架构成为一项经常性成本。

教训：[GraphQL11 的成本不仅仅是采用；还在于。它正在持续运行，并随着应用程序的成功而成长。

比较三者，规律就清晰了。 [当问题是过度获取和多个来源时，GraphQL12 可以节省社交提要。当数据很简单时，市政厅应用程序是免费的。当应用程序无纪律地扩展时，它会收取越来越高的运营价格，电子商务。

因此，成本不是 [GraphQL13 的一个特征。它是工具与问题之间的契合度以及团队随着时间的推移操作该工具的成熟度的函数。

第四种情况是值得的，因为在开放领域中很少会做出 GraphQL 与 REST 的决定，几乎总是从已经存在的 REST 进行迁移。想象一个新闻应用程序具有有效的 REST API，由于提要中的过度获取，该应用程序决定迁移到 GraphQL。

移民到这里的成本常常被低估。这不仅仅是构建新模式；的目的是在用户群迁移到使用 [GraphQL15 的应用程序版本时保持旧的 REST 运行。几个月来，该公司一直在并行运行两个 API，维护和安全足迹加倍。这种转换成本是真实的，并且在仅查看最终状态的比较中消失。

在示例中，团队会发现 feed 中的效率增益是真实的，但是两个 API 的共存所花费的工程量比优化 feed 在短期内节省的工程量要多。只有长期愿景才能证明这项投资的合理性，随着时间的推移，更多的屏幕会迁移到 [GraphQL16。

这个例子的要点是，[GraphQL17] 的成本包括从你所在的地方到达它的成本。迁移实时应用程序并不是要更改一部分；而是要更改一部分。它并行运行两个世界，直到过渡完成。无论谁决定迁移，都需要为这段旅程定价，而不仅仅是目的地。

不存在“GraphQL 很贵”或“GraphQL 很便宜”这样的说法。有“在你的情况下 GraphQL 贵还是便宜”。这三种情况表明，相同的技术可能是最好的投资，也可能是最差的投资，具体取决于您遇到的问题以及您如何操作它。

在做出决定之前，请在这三者中找到您的场景。如果您在社交媒体上认出了自己，那就去吧。如果您距离市政厅应用程序较近，请保存。如果您要转向电子商务，请在其单独出现之前准备好运营帐户。

如果您正在为您的应用程序权衡 GraphQL，并希望确定您的案例适合哪种场景，那么值得讨论。博客上还有另一篇文章，其中包含 GraphQL 采用清单，以及有关移动性能和 API 架构的文本。