GraphQLConf 2026

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

In GraphQL, a resolver is defined as “the internal function for determining the resolved value of a field.” Traditionally, resolvers live exclusively on the server—but should they? Many teams find themselves either duplicating business logic on the client or pushing client-specific concerns into backend code when trying to treat server models as view models.

This talk explores an alternative: client-side resolvers. With Relay Resolvers, clients can define fields that combine and transform data locally. We'll walk through how they work and guidance for deciding when logic belongs on the server versus the client.

The GraphQL Schema Documentation (https://graphql.org/learn/schema/) defines the __typename field as “a special meta-field that automatically exists on every Object type and resolves to the name of that type, providing a way to differentiate between data types on the client.” At Meta, we’ve learned that relying on __typename to delineate type on the client can actually be a foot-gun. Querying __typename for every object is clunky, increases payload size, creates backward compatibility issues for older, unupgradable clients, and isn’t sufficient for handling complex schema cases like nested abstract types.

In this talk, I’ll walk through specific scenarios where __typename falls short, and demonstrate how using a new metadata field, `is_fulfilled`, is better-suited to writing more robust GraphQL clients.

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.

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.

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.