Even ten years in, GraphQL continues to evolve—not just in code, but in connection. This year the Foundation has doubled down on transparency, support, and shared leadership: board minutes are now public, Subject Matter Experts have helped shape the conference agenda, and we'll be launching a new program live on stage! There are also updates on our existing initiatives including community grants and GraphQL Locals.

This talk is a thank you to the people behind the progress and a celebration of our growing constellation of contributors. It's also an invitation to step forward and get involved—one of the best ways to do that is by joining our new Community Working Group, giving passionate community members a voice in shaping the Foundation's directions and initiatives for the next ten years of GraphQL.

What if you could keep traditional UI pagination concepts, but with the performance and reliability of cursor-based pagination? In this lightning talk, you’ll learn how relative cursors enable fast, consistent pagination while preserving familiar UX patterns like “jump to page.” It’s a smarter, more robust approach to navigating data—ideal for modern APIs and real-world apps.

The GraphQL community has come together to standardize how people can build distributed systems with GraphQL as an orchestrator. In this talk I will explain the general idea that we have for GraphQL as an Orchestrator in this space and how the new specification is tackling this. We will look at the progress we have made since last GraphQL Conf in the GraphQL composite schema working group and also get some sneak peaks at our early RFCs and prototypes. I will outline how this new specification is taking the best ideas of existing solutions in the market to make the next big leap towards mainstream adoption. This will allow anyone to build tooling by implementing the spec or parts of the spec that seamlessly integrate with other vendors.

Turning a private GraphQL API into a public one comes with unexpected challenges. We’ll share how we approached this transition—starting from an existing internal schema that wasn’t shaped for external consumers—and the steps we took to expose only what was ready. Using Apollo Federation Contracts, we filtered out unstable or sensitive parts of the graph. Along the way, we defined best practices for the public schema, like cursor-based pagination, using oneOf for inputs and results. We’ll also touch on how we serve the schema through Hive Gateway with a supergraph setup, and the security measures we added, like depth limiting and complexity analysis. To keep things evolving safely, we rely on GraphQL Hive to track usage and guide deprecations.

If you’re thinking about exposing a GraphQL API—or just want ideas for keeping one clean and manageable—this talk will share what worked for us, what didn’t, and what we learned.

Jetpack Compose is a declarative UI framework for Kotlin and Android. Jetpack Compose makes it easy to describe your UI graph and build composable UIs.

On the other hand, GraphQL is a declarative language for your Data. GraphQL makes it easy to describe and query your Data Graph.

Sounds like a perfect match!

In this presentation, we'll take a look at the current mobile architectures and how they differ from web architectures.

We will dive into cache, offline mode and error handling and investigate how GraphQL can help mobile developers build more reactive and robust UIs.

Using real life examples from the GraphQL conf 2025 app, we well discuss patterns such as colocated fragments, optimistic updates, subscriptions and see how they fit in the mobile app development cycle.

While it will use some Kotlin, most of the examples can be applied to iOS and/or any other mobile platform.

If you're a web developer, I'm hoping to give you some talking point to start the discussion with your mobile teams. Let's unite frontend developers!

GraphQL error handling sucks. There, I said it.

Ever hunted through the errors list to figure out if a null was legit or caused by an error? If you're like me, you gave up and now treat nulls as "maybe errored, maybe absent, maybe both."

And nullability. Schema designers make anything that might fail nullable, producing partial responses when errors occur. But since anything can fail, now everything is nullable— and we're drowning in null checks. We recklessly cast to non-null or fall back to the empty string out of desperation. And we still don't know what's truly nullable.

No more.

This talk introduces a new, pragmatic approach, born from years of work by the Nullability WG. We propose a future where schemas reflect the true nullability of business entities, and error handling is where it belongs: in your code, not your data. Use your language's built-in tools to handle errors ergonomically; and drop the unnecessary null checks. When you read a null, it should mean one thing: the absence of data.

This isn't some distant ideal on the horizon of GraphQL's future; with just 512 bytes added to your GraphQL client, you can start adopting this today. Come see how.