Shopify 实现更快的广度优先 GraphQL 执行的历程

GraphQL powers Shopify’s data layer of commerce. We use it to serve deeply nested queries that scale geometrically—like fetching 250 products with 250 variants each—creating fan-out that GraphQL APIs frequently guard against. We support these patterns to make technology work for our merchants, never the other way around.

GraphQL 驱动 Shopify 的商业数据层。我们用它来服务几何缩放的深度嵌套查询——比如获取 250 个产品每个带有 250 个变体——产生 GraphQL API 经常防范的扇出。我们支持这些模式，让技术为我们的商家服务，而不是反过来。

However, such high-cardinality patterns do present real scaling challenges, and when we dug into traces we found an unexpected bottleneck: the majority of request time wasn't necessarily spent performing I/O—it was frequently spent running field resolvers that built the GraphQL response.

然而，这种高基数模式确实带来了真正的缩放挑战，当我们深入追踪时，发现了一个意外瓶颈：请求时间的多数并不一定花在执行 I/O 上——它经常花在运行构建 GraphQL 响应的字段解析器上。

The main culprit was GraphQL's conventional depth-first execution model and its hidden scaling costs. So we built something new: GraphQL Cardinal, a breadth-first execution engine that resolves each field once across all objects instead of once per object.

罪魁祸首是 GraphQL 传统的 depth-first 执行模型及其隐藏的 scaling 成本。所以我们构建了新东西：GraphQL Cardinal，一个 breadth-first 执行引擎，它针对所有对象只解析每个字段一次，而不是每个对象一次。

The result? Large list queries may see 15x faster execution with 90% less memory used, which can shave many seconds off P50 times, and we’re still discovering Cardinal’s full potential.

结果呢？大型列表查询可能看到 15 倍更快的执行速度，使用 90% 更少的内存，这可以将 P50 时间减少许多秒，我们仍在发掘 Cardinal 的全部潜力。

This post is an open letter to the GraphQL community. We'll walk through the hidden costs that we’ve observed in depth-first traversal, the breadth-first hypothesis that led to Cardinal, how the engine works internally, and what it takes to migrate a massive production stack to an entirely new execution model.

这篇文章是给 GraphQL 社区的公开信。我们将逐步讲解我们在深度优先遍历中观察到的隐藏成本、导致 Cardinal 的宽度优先假设、引擎的内部工作原理，以及将大规模生产栈迁移到全新执行模型需要付出什么。

Problems of scale

规模问题

Shopify's GraphQL-powered data layer supports deeply-nested structures with fan-out that GraphQL APIs frequently guard against. Fo...