GraphQLConf 2025

Effective caching is essential for building fast, resilient mobile apps especially when aiming for offline-first experiences. Apollo Kotlin and Apollo iOS offer a powerful Normalized Cache component tailored to GraphQL. In this lightning talk, we’ll showcase the latest advancements in both libraries, including support for pagination, cache expiration, and other new features designed to simplify and supercharge cache management on mobile.

What if your GraphQL schema could do more than provide data? What if it could help your app be more accessible from the start? In this lightning talk, we'll explore an innovative idea of embedding accessibility metadata directly into GraphQL schemas. Inspired by using Kotlin semantics in Jetpack Compose, imagine annotating fields with labels, roles, or screen reader hints that can be used to support screen readers, improve navigation, and even power automated accessibility testing. By adding custom accessibility annotations, tools could generate more accessible UI components, which enhances both the developer experience and the user experience. This is a call to rethink the developer experience and treat accessibility as a first-class concern. Let's reimagine GraphQL not just as a data layer, but as an inclusive design enabler.

Managing separate API definitions for REST and GraphQL APIs that serve the same underlying data can be inefficient and lead to duplicated efforts. At Pinterest, we are streamlining our API definitions and unifying our data models with TypeSpec. TypeSpec allows us to define our API shapes once and generate API schemas in multiple forms such as OpenAPI, Protobuf, and now GraphQL!

We’ve developed an open-source TypeSpec GraphQL Emitter which generates valid GraphQL schemas directly from TypeSpec definitions.

Join us for an overview of how TypeSpec and the GraphQL Emitter can streamline your API workflow. We'll explore:

* How TypeSpec's unified definition approach accelerates development across multiple API specs
* The inner workings of our open-source GraphQL Emitter
* Our wins and lessons learned while building the GraphQL Emitter

This talk will be perfect for anyone interested in GraphQL schema generation, unified API definitions, and vague Lord of the Rings references! See you there!

In theory, data loaders solve most "N+1" problems in GraphQL. In practice, they can be hard to implement, so they’re typically used only in performance-critical situations and often reactively, once inefficiencies surface. To achieve better performance, batching needs to be applied wherever possible.

This talk introduces batch resolvers, a more developer-friendly alternative to data loaders. While traditional GraphQL resolvers take a single input and produce a single output, batching resolvers take a list of inputs and return a list of outputs. A batch resolver can simply call a batch service API without worrying about data loaders.

When a developer provides a batch resolver, our GraphQL server automatically aggregates individual data fetches into a single call to that resolver. It can also apply heuristics to improve aggregation, for example by consolidating different selection sets for the same entity into a single input. This design not only makes application developers’ lives easier, but also allows the server to better optimize query execution by coordinating batch dispatching as part of a broader execution strategy.

Last year we introduced strict error handling - with @throwOnFieldError as an example of how this can be accomplished. This year, we’ll discuss how to safely roll it out.

You’ve had a GraphQL codebase that weakly handled server-side errors for years. Now, you have the tools (directives, hooks, handlers, and language features) that let you treat field errors properly. However, it’s a daunting task to suddenly explode queries en-masse by flipping a switch. This move is powerful, but requires a thoughtful and data-driven approach to do safely.

In this talk we’ll cover:
* Preparing the groundwork for migration to stricter error handling
* Using data to make informed decisions about fragment/query behavior
* Gating your change at a singular point
* Scaling the rollout to a large codebase
* How we’re approaching this rollout at Meta

Caching is one of the most powerful tools for improving API performance—but in a federated GraphQL architecture, stale data can quickly become a serious challenge. In this session, we will dive into how event-driven patterns can enable precise cache invalidation at the subgraph level, keeping your data fresh without sacrificing speed.

You will learn key design principles, practical integration strategies for GraphQL subgraphs, and the business impact of a smarter caching approach. We will also explore real-world use cases and demonstrate how CloudEvents can standardize event-based workflows across your architecture. Whether you are optimizing an existing caching layer or just beginning your caching journey, this talk will equip you with practical strategies to reduce latency, lower infrastructure costs, and deliver more reliable experiences to your users.

When adopting GraphQL, teams diligently follow "best practices" without realizing they're actually choosing between two fundamentally different approaches: designing schemas to serve UI components (frontend-first) or to represent domain models (structure-first). This distinction is rarely framed as an explicit choice in GraphQL literature, with most examples showcasing the structure-first approach by default.

Yet this initial decision shapes everything from your team structure to how you handle breaking changes—and if you start with a structure-first approach, it's especially difficult to unwind that decision later. In this session, we'll explore the critical differences between these philosophies, examine how they manifest in real schemas, and analyze the trade-offs each approach presents. You'll see how changes that feel natural in one approach become deeply problematic in the other, and learn to identify which patterns your team has already begun to follow.

Any company that wants to innovate deals with change. Within GraphQL that often means introducing new fields but also deprecating old fields & types.
The faster you can get rid of these old fields & types the less complex your architecture is and less complexity means an easier time building new features!

We saw this problem and got tired of the endless “please migrate away from field X to field Y before Z” emails, which were often not even sent to the right group of consumers!

We automated this process by building a slack bot that uses production analytical data to figure out what clients are using deprecated fields and automated the communication!

Ever wondered if two seemingly different GraphQL queries actually return the same data? Or how to ensure that complex queries—packed with type conditions and directives like @skip/@include—still mean the same thing after a major refactor? In this talk, we’ll explore a novel static analysis technique that efficiently checks whether one query’s response is always a subset of another’s. By performing this subset test in both directions, we can reliably determine query equivalence—bringing new clarity to complex GraphQL operations.

"There are only two hard things in Computer Science: cache invalidation and naming things".

GraphQL provides many benefits over other query languages. Federation builds on top of this foundation to provide even more flexibility and power. But even with all that GraphQL has to offer, the problem of naming remains.

In this talk, Jeff Dolle, from The Guild, will share what he's learned about schema design: proven design philosophies, designing for forward compatibility, exposing errors through types, and tips for how to avoid ambiguous or misleading type names.

Together, we will then go through an example product design meeting: taking user stories and building a complete GraphQL schema.