GraphQLConf 2026

Pretty much every major GraphQL execution implementation follows the same pattern: depth-first traversal. But the spec doesn’t require this. At Shopify, we challenged that status quo and rewrote GraphQL execution to run breadth-first.

Here’s how it works: instead of running a field resolver repeatedly across each object in a list during its depth pass, we execute each field resolver only once per selection with a complete breadth of objects spanning the response. The napkin math is compelling—5 fields resolved across a list of 100 objects running depth-first will produce 500 resolver calls + lazy promises, while running breadth-first will only produce 5. We’ve seen dramatic results with some large list queries shaving many seconds off their end-to-end response times.

This talk will cover:

* Why depth-first has hidden costs that scale linearly.
* How breadth-first inverts the cost model.
* Why dataloaders are a hack.
* The trade-offs we accepted.
* How we're incrementally migrating to breadth execution.

If you've ever been concerned that CPU-bound GraphQL performance doesn't scale well, this talk offers a new perspective—and proof that challenging conventions can pay off.

Optimizing wire size is in WhatsApp's DNA. In the early days, we transformed verbose XML into a compact binary protocol (WAP) that helped us serve users worldwide on constrained networks. Now, as we migrate to GraphQL, we faced a new challenge: JSON responses were 30% larger than WAP-encoded equivalents. This talk tells the story of how we solved that problem—by leveraging GraphQL's type system to outperform not just JSON, but WAP and protobufs too. We'll share the technical approach (implementing Argo), the results (27-50% smaller responses), and why this represents the next evolution in efficient data transfer for Meta's apps.

Learn how to lower latency in your applications by streaming your GraphQL responses using the @defer and @stream directives. Learn the trade-offs of when to use these new directives and how they differ from GraphQL Subscriptions.

@defer and @stream have been in development for some time now and have gone through many iterations. Learn about the motivation behind these changes and how they will lead to scalable GraphQL servers and efficient clients.

GraphQL simplifies client development through flexible, expressive data queries. However, in serverless production environments, that flexibility can quietly increase latency and infrastructure cost.

In AWS-based architectures using Lambda, DynamoDB, Aurora Serverless, and distributed services, resolver design and query structure directly impact execution time, cold starts, and overall spend. Unlike REST, GraphQL shifts cost dynamics to query complexity and resolver fan-out, and often in ways teams don’t anticipate until production traffic scales.

This session examines common performance and cost anti-patterns in serverless GraphQL systems, including N+1 resolver cascades, unbounded query depth, over-fetching, and inefficient resolver fan-out. We’ll explore how these patterns affect Lambda duration, concurrency, and downstream data stores.

Attendees will learn practical mitigation strategies such as batching with DataLoader, caching and persisted queries, query complexity limits, schema guardrails, and observability techniques to detect bottlenecks early.