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.

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!

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.