GraphQL celebrated it's 10 year birthday last year, today it's PostGraphile's turn! Hear from maintainer Benjie about the origins of the project, the lessons learned along the way, and how the project has evolved to meet the needs of its users despite being MIT-licensed OSS.

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.

This ad-hoc talk is just Benjie (and Michael Staib from ChilliCream!) riffing about some of the work that's going on in the GraphQL Working Groups currently. Topics covered include:

• GraphQL Spec Freeze July 2025 - a new spec cut is coming!
• Incremental Delivery
• Schema Coordinates
• Fragment Arguments
• Nullability
• Operation Descriptions
• Service Capabilities
• GraphQL-over-HTTP
• Partial Success Status Code
• Composite Schemas
• GraphQL.js v17
• GraphiQL v5
• OpenTelemetry
• Documentation Overhaul
• Community Working Group
• Website Redesign
• GET INVOLVED!