GraphQLConf 2026

GraphQL APIs face a unique threat landscape: deeply nested queries cause resource exhaustion, introspection exposes entire schemas, and mutation variables carry injection payloads past traditional WAFs. Yet most Go-based GraphQL servers ship with zero security middleware between HTTP and resolver execution.

I introduce GraphQLShield, an open-source Go middleware bringing defense-in-depth to GraphQL APIs through three layers: (1) Static schema analysis detecting cyclic types, missing depth limits, and sensitive field exposure before deployment; (2) Runtime CWE-aware input sanitization catching SQL injection, XSS, command injection, path traversal, and NoSQL injection in GraphQL variables — bridging go-safeinput’s MITRE CWE Top 25 coverage to GraphQL; and (3) Resolver code auditing inspired by gosec and cryptoguard-go flagging insecure crypto, hardcoded secrets, and missing auth checks.

A quick demo shows GraphQLShield intercepting 7 attack vectors against a gqlgen API, from SQL injection in mutation variables to depth-based DoS, while legitimate requests pass cleanly. Attendees leave with a zero-dependency Go library covering 14 CWE vulnerability classes across static and runtime analysis.

@deprecated is usually treated as a client-facing hint. However, in federated GraphQL, it can evolve into a set of patterns that shape governance, runtime behavior, observability, and even gateway planning. In this lightning talk, I’ll take @deprecated on a five-stop journey across the federation lifecycle — 1) schema hint, 2) schema shaping, 3) runtime feedback, 4) client-aware telemetry, and 5) gateway power. I’ll close with a brief developer experience bonus — how structured deprecation metadata can feed code-gen/IDE tooling to suggest non-deprecated alternatives while queries are being written. The goal of the talk is to share a practical mental model and guardrails for keeping large federated graphs evolvable, observable, and safe.

Use Apollo Client v4 in React with Tanstack Router.

We’ll be using GraphQL code generation from your schema, preloading data at the router level, optmistic updates, and using Apollo’s cache to eliminate unnecessary refetching and rerenders. You’ll see how smart cache usage and colocating queries lets components read data directly where they need it which will reduce prop drilling. The goal is to show how “modern” Apollo Client patterns fit naturally into today’s React architecture to create apps that feel both simpler to reason about and noticeably more performant.

Large engineering organizations now run GraphQL at the center of their product stacks, serving billions of requests across web, mobile, and internal clients. The questions have shifted accordingly. The interesting problems are no longer about whether to adopt GraphQL, or how to write a resolver. They are about what it takes to operate GraphQL reliably, evolve it safely, and scale the humans who work on it.

This panel brings together engineers from companies running GraphQL in production at large scale to compare notes on the realities of that work. Each panelist has spent years operating a GraphQL gateway or federated graph that fronts hundreds of services and thousands of fields, owned by dozens of teams. The goal of the session is a candid, technical conversation about what has worked, what has not, and what they would do differently.

This session is intended for engineers and tech leads who already run GraphQL in production or are planning to, and who want to hear from peers operating at similar or larger scale. Familiarity with GraphQL fundamentals is assumed. No introductory material will be covered.

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.

At a company like Booking.com, every sensitive field in the GraphQL schema has more than one team with a legitimate claim on it — Security, Identity, Legal, Privacy, Data Governance, the Traffic Gateway, the Federation Platform, and the hundreds of domain teams that own the data itself. When that many stakeholders need to agree on what "authorized" means for a single field, you don't have a security problem; you have a coordination problem. And solving it as security only makes it worse.This talk shares how we turned that coordination problem into a contract using a single federation directive — @policy. Domain teams author rules for the data they own. Privacy and Identity contribute cross-cutting concerns. Other domains compose by reference instead of re-authoring. The router is the only place enforcement happens. One audit trail. No cross-team meetings.

What you'll learn:

• Why multi-stakeholder access control is a coordination problem, not a security one

• How @policy becomes the coordination contract between domain teams, cross-cutting authorities, and the federation platform

•  The single-enforcement-point + bounded-authorship + free-reuse architecture — and how it lets new teams adopt without coordination overhead

GraphQL and Federation solve real problems: replacing hand-written orchestration with a declarative, typed contract between clients and backends. That model works. But the landscape is shifting — AI agents are becoming first-class API clients, and they need to compose across services, reshape responses, and build workflows faster than coordinated schema design allows.

The core insight: one graph doesn't have to mean one API. What if the supergraph were less a single schema and more a catalog of data and services? That shift opens up a different kind of client language: one with expressions, data restructuring, and the ability to call non-GraphQL APIs directly.

I'll show the result of our explorations: a language that keeps what makes GraphQL powerful — strong typing, composability, field-level selection — and extends it with the primitives clients need to work across service boundaries. It should feel familiar and is designed for any client — web, mobile, and AI agents alike. I'll explain what we learned from pushing GraphQL and Federation to their limits, and make the case that breaking the mold doesn't mean starting over.

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!

When we give AI agents access to our GraphQL APIs, we introduce a new class of distributed system challenges: non-deterministic queries, potential N+1 floods, and authorization bypasses. How do we ensure our "AI-generated" queries are safe and efficient?

This talk bridges the gap between AI Quality Engineering and GraphQL governance. Building on my work designing evaluation frameworks for multi-agent systems, I will present strategies for monitoring and governing agents that interact with GraphQL endpoints. We will discuss how to implement "Semantic Rate Limiting" (analyzing query complexity vs. user intent) and how to evaluate the accuracy of agent-generated GraphQL syntax using "LLM-as-a-Judge" frameworks.

We will also cover the "Human-in-the-Loop" aspect: using GraphQL subscriptions to stream agent reasoning to human supervisors for real-time validation before a mutation is executed. Attendees will learn how to open their Graphs to AI without compromising on security or performance reliability.

Blue-green and canary deploys are table stakes for application code, but they’re surprisingly hard to get right for GraphQL. Routers often just “pull latest” schema, rollbacks mean republishing and recomposing, and it’s nearly impossible to answer a basic incident question: “What schema was this request actually hitting?”. After testing in a staging environment and deploying to production, we often find edge cases that broke the assumptions we made in the testing phase.

This talk is an engineering case study. I’ll walk through the design journey that led us to a blue-green deployment model for GraphQL built on immutable schema artifacts and explicit rollbacks. We’ll unpack the constraints (federation, many subgraphs, multiple environments), the dead-ends we hit, and the principles that finally worked.

You’ll leave with a mental model and concrete patterns you can apply to your own GraphQL infrastructure, irrespective of tooling: how to structure blue-green router fleets, how to pin to exact schema versions, how to do instant rollbacks safely, and what to log so you can always reconstruct “what was live where” when production gets weird.

You know how to build client apps—but where do client developers fit in the new world of ChatGPT and MCP? If you've used GraphQL before, it turns out your knowledge translates directly. This talk demonstrates how to build MCP apps using Apollo's AI apps client and MCP server with patterns you already use:
1. Fragment colocation → Tool design: Structure MCP tools like component data requirements
2. Query optimization → Tool call patterns: Minimize LLM roundtrips with the same performance thinking
3. Type safety → Tool schemas: Apply GraphQL's type discipline to MCP definitions
A live demo builds an MCP app querying a GraphQL API, showing how best practices from GraphQL client development apply to OpenAI and MCP apps.

The GraphQL community has come together to standardize how distributed systems can be built with GraphQL as an orchestrator.

In this talk, I will outline our vision for GraphQL as an orchestration layer and explain how the emerging Composite Schema specification addresses the challenges of composing distributed graphs. We’ll review the progress made since the last GraphQLConf within the Composite Schema Working Group and take a look at early RFCs and experimental prototypes.

The specification builds on the strongest ideas from existing federation approaches in the ecosystem, distilling them into a vendor-neutral standard. Its goal is to enable interoperability — allowing vendors, platform teams, and open-source projects to implement the specification, or parts of it, in a way that integrates seamlessly across tools and ecosystems.

This session is a community update on the work happening under the GraphQL Foundation to standardize Federation: the problems we are solving, the principles guiding the design, and what comes next.

So you’re a maintainer of a GraphQL system. Whether it’s a federation gateway, a complex client library, or a custom executor—how do you know that it’s capital-C Correct?

Your tests are decent, and they seem to pass, but what about the test cases that you didn’t think of? Did you remember to handle @skip directives on fragment spreads? What about when those directives use variables? Or when you spread an abstract type in an abstract scope?

Would you trust your system to serve million-dollar transactions?

This session will cover how probabilistic testing can be applied to complex GraphQL systems to find bugs in places we wouldn’t have thought to look. We’ll discuss how Airbnb leveraged this approach to launch a novel GraphQL engine with 0 spec conformance bugs, and how you can apply these same techniques to build unshakable confidence in your own systems.

Wayfair is embedding AI and MCP into every stage of the developer workflow to unlock speed without compromising quality. From Schema Copilot (inline reviews) to AI Mocking (intelligent test data generation) to AI-Assisted Schema Documentation (auditing and auto-generating descriptions across 200+ subgraphs), these purpose-built tools streamline workflows, reduce friction, and scale engineering excellence—helping teams ship faster with greater confidence and consistency. Join to learn how AI and MCP cut busywork so Wayfair’s devs can ship faster with confidence.