GraphQLConf 2026

Help shape the future of GraphQL! Join GraphQL Foundation Board Members, TSC Members, and other community leaders for a public meeting about goals and priorities for 2027, and help us celebrate 2026's wins.

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.

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.

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

What if your GraphQL API could understand what developers need and generate valid operations from plain English? This talk introduces graphql-embedding, an open-source toolkit that parses GraphQL schemas into vector embeddings, stores them in a vector store, and uses a multi-agent LLM pipeline to generate validated GraphQL operations from natural language input.

The architecture is fully modular: swap vector stores between PGLite for local development and PostgreSQL for production, choose from Ollama, OpenAI, or Anthropic as LLM providers, and extend with your own. A key design decision was bundling a lightweight embedding model directly in the package, enabling local CPU inference with no external API calls, cloud dependencies, or GPU required. The entire pipeline to generate a operation works with small, efficient models like QWen 2.5 running locally via Ollama.

Everything ships as a VS Code extension called GraphQL Workbench, putting schema embedding and natural language operation generation directly in the developer's workflow. All packages, models, and the extension are fully open source under the MIT license.

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.

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.

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.

Fragments—an indispensable tool for modularizing data requirements alongside client code, but also a denial-of-service attack vector for servers. Security guides will tell you to mitigate by validating queries and performing cost analysis, usually via field costs and list sizes. However, this focus on field execution can distract from how fragments affect the rest of the server stack. In this lightning talk, we explore the attack patterns and mitigation strategies for the fragment-based vulnerabilities at the core of CVE-2025-31496, CVE-2025-32030, CVE-2025-32033, and CVE-2025-32034.

GraphQL has always been a community driven project. In this closing keynote, we will look at what the GraphQL Working Groups have been building and the progress made across the specification and ecosystem. We will also highlight the GraphQL GAP proposal and explore how it can open new opportunities for collaboration. Join us as we reflect on how far GraphQL has come and how the community can help shape what comes next.