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.

Rate limiting in GraphQL APIs goes beyond the traditional approaches used in REST APIs. Regular techniques fall short when handling complex queries and preventing abuse. In this lightning talk, we will explore creative strategies for overcoming these challenges within the unique context of GraphQL's single endpoint architecture. We will also discuss practical techniques and dive into real-world examples that demonstrate how to optimize rate limiting in your GraphQL APIs and ensure the scalability and security of your applications.

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.

Traditional GraphQL servers execute queries field by field with a depth-first algorithm as defined in the GraphQL specification. In contrast, GraphQL federation gateways need to partition the query and retrieve chunks of data from external data sources, creating new challenges. We'll present how we solved those challenges with a focus on performance.

The first, query planning, is to find the best possible plan with the multiple possibilities federation offers to unify your data and the various data sources with their requirements. We express this problem as a graph of possibilities and solve it as a Steiner Tree problem. The second challenge is performant execution. As we need to read and write overlapping chunks of the response in parallel, it's hard to be as efficient as a traditional GraphQL server writing a response iteratively with independent fields. We build an execution DAG with field dependencies, parallelizing work as much as possible without any lock on the response. We also pre-compute the expected data shape to ingest and validate incoming data into the response without any intermediate memory allocation.

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

Imagine having a federated GraphQL query builder customized to meet unique software infrastructure requirements—have you ever dreamed of such a tool? If so, please join us for an exciting session where we uncover LinkedIn’s code first approach to querying entity-oriented data with federated GraphQL on top of backend gRPC services. Discover how our solution leverages the advanced capabilities of gRPC for enhanced performance, low latency, and multi-language support, while achieving seamless integration with our established Rest.li framework. We will dive into the motivations behind adopting this strategy, the intricate challenges encountered, and the significant improvements in developer experience and productivity it brings. With real-world examples and performance benchmarks, witness how this approach modernizes our service infrastructure, leading to more efficient and scalable solutions.

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.

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.

Error handling is a critical aspect of developing robust GraphQL applications. Misuse or misunderstanding of errors can lead to applications that fail to function correctly, causing frustration for both developers and users.

In this talk, we explore how to effectively manage errors in GraphQL, ensuring they are wrapped in a useful way, the implementation details are hidden behind them, and common design pitfalls are avoided.

Mediaset, one of Europe largest free broadcasters, owns and manages more than ten consumer-facing applications across web, mobile, and smart TV platforms, leading the Media and Entertainment ecosystem in Italy and Europe. Historically, each of these apps (managed by distinct development teams) interacted directly with several different backend APIs to serve content to customers, resulting in redundant development efforts, inconsistencies between platforms and enormous and useless network transfers.

In this session we will present how, by creating a carefully designed GraphQL schema, we managed to transition each of them to a more streamlined approach, where the backend complexity and variety is hidden from the frontend integrations. We will dive into the choices made, the GraphQL features that we leveraged (one among all, Trusted Documents to exploit CDNs and improve security), the issues that we've encountered while building the system, and the benefits that we gained from all perspectives: user experience, development perspective, feature delivery and time to market.