GraphQLConf 2026

In the rush to "break the monolith" through GraphQL Federation, organizations can go too far and end up with an explosion of subgraphs. At scale, this can lead to a different kind of pain: high operational overhead, reliability issues, and ultimately, a degraded graph quality. This session explores how to pivot from "splitting" to "merging" without impacting the customer.
The presentation will dive into the workflow developed by Brex to consolidate federated subgraphs safely and reliably, covering:
•⁠ ⁠The Why: Identifying the tipping point where service fragmentation hurts more than it helps.
•⁠ ⁠The Strategy: A zero-downtime workflow for merging services covering code migration, schema composition and traffic shifting
•⁠ ⁠Reliability: How to ensure schema integrity and 0 customer impact during the transition.
•⁠ ⁠Outcomes: How the consolidation improved our graph design and simplified our overall architecture.

Attendees will leave with a framework for evaluating when federation boundaries are hurting more than helping and a roadmap for executing a "subgraph smash" in their own federated infrastructure.

Parsing a GraphQL query generally has negligible cost. But what happens your front page query has millions of QPS, 10s of thousands of fields, and there are hundreds of versions of the query? At Meta, we've found that parsing becomes a significant bottle neck under these constraints.

In this talk, we dive into server-side optimizations we built to handle persisted documents beyond simple LRU caches. We will cover:
- Lazy fragment parsing. We delay parsing a fragment until the executor encounters a spread that matches the fragment's type, using offset maps to jump through the document text.
- Traffic based caching. We cache pre-parsed structures taking into consideration CPU savings and memory cost.
- Fragment inlining to reduce overhead in the CollectFields step.

Attendees leave with deep understanding of performance considerations of GraphQL execution engines. I hope other GraphQL server implementations can consider adopting similar strategies to better serve a larger variety of traffic patterns.

How do you expose all the internal tools to the Agents is the question everyone is asking today. Turns out we already expose all the things people can do with our internal tools at Meta through GraphQL and LLM Agents are now able to write GraphQL queries, so... come to this talk to see how both work wonderfully together!

AI coding agents are now a daily reality for GraphQL developers, yet there's a persistent gap between what agents can do and what they actually know. Without guidance, they generate anonymous queries, skip variables, rely on deprecated patterns, and miss conventions experienced teams consider obvious. Every conversation starts from zero. Agent Skills are an emerging answer: a lightweight, open format for encoding expertise that agents can automatically apply. In a short time, the community has begun building Skills that teach everything from schema usage to client caching, and the ecosystem is evolving fast. This talk surveys the current state of GraphQL Agent Skills: what they are, how they're authored, how they plug into AI tools and workflows, and how they complement MCP. As the creator and maintainer of Apollo Skills, I'll share what we've learned building and shipping them. Through real-world examples, we'll see how Skills help agents design a schema safely, write the right operations, and recover from mistakes. We'll examine design trade-offs, emerging patterns, and open challenges still ahead. You'll leave knowing how to make your graph work better with AI agents.

GraphQL is often framed around multiple clients, external consumers, and solving over/under-fetching. But what if you have one client, fragmented internal APIs, and colleagues as your consumers? This talk explores that different axis—and why GraphQL still matters.

At trivago, we built a second GraphQL Gateway to unify internal services. What started as admin tooling became something more: a lens that surfaced hidden system relationships, a catalyst for cross-team collaboration, and now a foundation for AI-assisted tooling enriched with human-written business context.

This session shares honest lessons from six years of running an internal-facing gateway. You'll hear how we unified services without imposing upstream requirements, fostered collaboration across previously siloed teams, and designed audit logging around user intent—not just technical calls. Whether or not this specific approach fits your context, you'll leave with a broader perspective: there's more to GraphQL than its typical framing suggests.

In a world where context is limited, what do we need from GraphQL to build composable, type safe products?

GraphQL is a technology well-loved by frontend engineers, but often leaves backend engineers struggling with boilerplate code and N+1 performance issues. This talk introduces Joist, a "GraphQL-first" TypeScript ORM that uses codegen, resolver scaffolding, and deep dataloader integration to bring Rails-level productivity to Homebound's 500+ table GraphQL/Postgres majestic monolith.

GraphQL offers a popular way for developers to access and interact with data. However, integrating GraphQL with enterprise databases often requires custom middleware, complex resolvers, and maintenance overhead. With Oracle AI Database 26ai, this changes: developers can now use GraphQL queries natively in the database, leveraging automated schema inference and built-in parsing with no loss of performance or scalability.

In this session, we will demonstrate Oracle’s first-class GraphQL integration, including the new table function that lets you run GraphQL queries as native SQL. We will showcase:

- How to map and query relational data with GraphQL, with built-in features for joins, predicates, ordering, & calculations.
- How LLMs can generate valid GraphQL queries from natural language, making API access approachable, and why targeting GraphQL via LLMs often delivers safer, better experiences than translating NL to SQL.

Whether you’re an architect modernizing data APIs or a developer working with complex schemas, this session will help you take advantage of the best of both relational databases and the GraphQL ecosystem, with added automation from today’s AI advancements.

The steps we took at implementing a GraphQL gateway first in JavaScript, and following those steps in Rust again.
Advantages of JavaScript and disadvantage of lack of diversity in the GraphQL Rust ecosystem.
Is Rust worth? Is it just performance? How hard was it to rethink everything done in the JavaScript version?

As teams adopt the Model Context Protocol (MCP), they often run into a new problem: tool sprawl. Every backend API turns into its own MCP server, each with separate schemas, auth, versioning, and deployment concerns. What starts as a clean integration quickly becomes hard to manage. In this talk, I'll show how GraphQL can act as a unifying layer for MCP using GraphQL capabilities like schema introspection and persisted documents. By exposing multiple backend services through a single GraphQL API and connecting it via one MCP server, LLMs gain access to a rich, strongly typed interface without an explosion of tools. We’ll walk through a practical architecture and share patterns for keeping MCP systems scalable, discoverable, and governable beyond early experiments.

Left to its own devices, software companies ship its own team structure (Conway’s Law). Scale leads to data silos, unclear ownership, and an incoherent GraphQL schema. Zillow pushes back against this natural entropy.
Organizing data post hoc is untenable — trying to keep up with the legions of changing SaaS systems is a losing battle. The schema must be organized at the data producer end. This is the story of Zillow’s journey to bring order to a chaotic GraphQL schema. Starting with its most critical data domains, listings and customers, Zillow has built a canonical data schema in its federated graph, that aligns its multiple business units and streamlines data sharing.

To run GraphQL in production with confidence, we need more than just uptime checks and HTTP 200 - we need deep visibility into the graph itself.

In this talk, we will explore how to implement the three pillars of observability: traces, metrics, and logs - specifically for GraphQL.

We'll explore OTel and GraphQL, allowing you to trace requests from the gateway down to individual Federation subgraphs and deeper.

Finally, we will look at how to leverage dedicated tooling like Hive Console to make sense of this data.