GraphQLConf 2026

How do you power a product where every page layout, module, and slice of content can change daily—across hundreds of millions of devices—without shipping a new client every time? In this talk, we’ll dive into how Netflix evolved its GraphQL APIs from traditional “data fetching” into a server‑driven UI platform, enabling rapid product innovation and page updates without requiring app releases across a massive device ecosystem. We’ll walk through the architecture that lets servers describe dynamic page structure and behavior, how those contracts scale across many product surfaces and experiments, and the performance and reliability lessons we learned operating this at Netflix scale. When we built this system, we found almost no public examples of similar patterns, so this session is intentionally practical: we’ll share concrete schema patterns, client rendering strategies, and tips you can apply to your own feeds, homepages, and highly dynamic experiences—whether you’re working at Netflix scale or just starting to stretch GraphQL beyond CRUD.

GraphQL isn't just an API technology—it's the perfect foundation for AI agents and LLM-powered applications. At Starbucks, we built GraphQL platforms at massive scale (180M+ queries/day, 10,000 stores, 31M+ app users) before GenAI became mainstream. Now, as we explore AI integration, we're discovering that GraphQL provides fundamental advantages for AI that are impossible with REST.

This talk explores the AI systems we're building on our existing GraphQL infrastructure:

In-store AI assistant (planned for Order Engine GraphQL BFF)
Mobile/web AI platform (exploring on Apollo Supergraph)
On-call automation using Model Context Protocol (MCP) servers
You'll learn how GraphQL reduces AI token costs by 75x, enables zero-configuration AI tool discovery, provides built-in guardrails through type systems, and why federation is the perfect architecture for enterprise AI agents. Real demos, proven patterns, lessons from building GraphQL at scale.

GraphQL's rich type system makes it an ideal foundation for agents to explore and work with APIs.
The SDL provides the structure agents need to reason about capabilities and data.
Queries let them retrieve information, while mutations enable them to take action.

In practice, however, production GraphQL schemas are often too large to fit in the context window and difficult to understand without additional context.
So what if agents could interact with any GraphQL API in a generic, reliable way?
In this session, we'll look at the challenges of agentic interactions with GraphQL and how semantic introspection could unlock a new way for agents to navigate the schema and interact with GraphQL APIs more reliably.

GraphQL Codegen has been the go-to tool for generating types for GraphQL clients for over a decade. But as use cases grew, so did the friction: excessive generated code, complex setups, and growing confusion among users on how to use the output.

In this talk, we'll explore a new client-focused Codegen setup that rethinks those trade-offs. You'll see how we drastically reduce generated output, ensure correct and predictable types, and provide a smooth migration path from existing tools without sacrificing flexibility or safety.

We'll also dive into the story behind the change: a collaboration between Eddy (The Guild) and Igor (Yelp), sparked by a single question and shaped by open discussion across time zones. It’s a look at how community feedback, real-world constraints, and trust can drive the biggest evolution in Codegen’s history.

A new approach to GraphQL execution, enabling engineers to build next-level efficiency into new or existing GraphQL APIs. This declarative approach to execution eliminates the many pitfalls of traditional resolvers and optimizes communications with your business logic. This is achieved through understanding the request's full data requirements and planning the best batched execution strategy before requesting anything from the business logic. This decoupling of data fetching from the GraphQL request shape results in fewer and more efficient operations against your backend services and data sources, eliminating both over- and under-fetching on the backend along with deduplication of redundant work, leading to reduced operational costs and delightful user experiences! A passion project of a founding GraphQL TSC member, this MIT-licensed open source technology has already been in production at a number of companies for over a year!

At Airbnb, our GraphQL gateway is a multi-tenant serverless platform hosting 500+ tenants and 1.5M+ lines of application code. Like many large GraphQL systems, it operated as a "shared fate" architecture. To mitigate this risk, we embarked on a multi-year journey to implement traffic sharding at different levels of sophistication. We started with shuffle sharding to reduce the blast radius of any single bad operation. We then added targeted sharding to separate online from asynchronous traffic, to rapidly quarantine misbehaving operations, and to improve the signal-to-noise ratio for our automated canary analysis. Most recently, to mitigate the risk posed by tenants that are used by lots of operations (and thus could bring down lots of shards), we have been working on tenant-aware sharding that minimizes the blast radius of such tenants.

We will cover how we architected our sharding solution and how it improved our operational abilities. You will gain a clear understanding of how our implementation tradeoffs have fared over time, key production insights gathered since rollout, and strategies to evolve a GraphQL gateway towards greater isolation without fragmenting the API surface.

Producing valid and realistic mock data for prototyping and testing has been an unsolved challenge for years. Mock data is tedious to write and maintain, but attempts to improve the process such as random value generation and field stubbing fall short as they lack essential domain context to make test data realistic and meaningful.
In this talk, I’ll share how we’ve reimagined GraphQL mocking at Airbnb by combining existing GraphQL infrastructure, rich product and schema context, and LLMs to generate convincing, type-safe mock data simply by adding a directive (@generateMock) to a field or operation:
- How integrating LLMs that are highly contextualized by a schema, documentation, and UX design into existing GraphQL tools drives a leap forward in the speed and quality of mock data creation.
- How a directive-driven approach lets engineers generate production-like, schema-conformant mock data without writing code.
- How integrating generated mock data into the GraphQL client runtime can enable engineers to build and test clients before server implementation.
- How this strategy guarantees that generated mock data is correct, deterministic, and stays in-sync with the server schema.

Trusted documents (persisted queries) are one of the most powerful tools in the GraphQL security and performance toolkit. By restricting your API to only pre-approved operations, you eliminate entire classes of attacks, reduce payload sizes, and gain full visibility into client behavior. Yet most struggle to adopt them – the tooling is fragmented, the workflow is manual, and the deployment story is an afterthought.

What if your entire platform natively supported trusted documents from end to end? In this talk, I’ll show what becomes possible when persisted queries are first-class citizens of your GraphQL platform – from registration and version through CI/CD validation to production deployment and rollback. But trusted documents aren’t just for GraphQL clients. I’ll explore how they unlock new capabilities: exposing GraphQL operations as simple REST endpoints, and even powering MCP tools for AI agents – all built on the same foundation of pre-approved, governed operations.

You’ll leave with a clear picture of what a complete trusted documents platform looks like and practical steps to get there.

What if a city could run as a GraphQL server?

In this talk, we model San Francisco as a modular GraphQL runtime powered by Viaduct. Instead of stitching together microservices or configuring external gateways, we organize zoning, building permits, transit, and census data as domain modules inside a single distributed graph engine.

Using real public datasets from the City of San Francisco and the U.S. Census, we demonstrate how tenant modules compose into a unified schema, how execution is coordinated across domain boundaries, and how teams can evolve parts of the graph without central bottlenecks.

We introduce a lightweight Skills SDK that abstracts runtime configuration and enforces clear ownership rules, making modular graph design approachable.

Finally, we connect an AI client to the server to demonstrate structured, explainable reasoning over live city data.

All demo code and schema modules will be open sourced for attendees to explore and extend.