Another year, another successful GraphQL Conference — this time hosted for the first time in the Netherlands, in Amsterdam! The community came together once again, this time to celebrate 10 years of GraphQL.
Over three packed days, attendees enjoyed workshops on real-world solutions, case studies from companies betting big on GraphQL, and deep, exciting talks from industry veterans and thought leaders. Everyone who cares about GraphQL and its ecosystem was there.
Picture by Taz Singh
From FAANG engineers sharing their experiences at scale, to businesses of all sizes presenting their success stories, to GraphQL Working Group members tackling complex problems face-to-face—it was a program that could make any GraphQL enthusiast happy.
As always, it was a great opportunity to finally meet the people behind those outdated GitHub avatars—the driving force of this vibrant community.
We exchanged ideas, learned about different ways GraphQL is used, and saw firsthand a diverse and healthy ecosystem where many solutions and vendors can thrive — whether through a federated approach or a monolith.
And of course, there were a ton of announcements!
Big Announcements
- 🎉 After years, the brand-new graphql.org website was launched at the conference—which we were proud to help build.
- 📜 A new GraphQL Spec version is here!
Countless contributors made this possible. Among the quality-of-life improvements (like schema
coordinates and document descriptions), the highlight is the
@oneOfdirective for input objects—finally enabling input unions. Huge milestone! - 🚀 We launched Hive Router, our high-performance federation router built in Rust. We even published a benchmark comparing all available solutions. The feedback has been phenomenal, and we’re excited to polish it for production use.
- ⚡ We also released Hive Gateway v2, our JavaScript federation gateway—packed with exciting new features like improved OpenTelemetry support, event-driven federated subscriptions (EDFS), better logging, and intelligent request deduplication. The extensive workshop led by Denis Badurina and Arda Tanrıkulu showcased how feature-rich, mature, and easy it is to build a federation gateway for your subgraphs.
- 🛠️ Finally, we shipped a new major version of GraphQL Code Generator, massively improving the developer experience for building federated GraphQL servers. Eddy Nguyen shared how to use the server preset in a session at the conference.
We had a blast at our booth — diving into technical discussions, exchanging ideas, or just chatting and having fun with the amazing developers who came by.
Key Takeaways
Let’s highlight and reflect a bit on the main takeaways from talking with various folks and attending sessions and workshops loaded with knowledge.
Federation is going strong
Federation adoption keeps accelerating.
What used to be a space with a single dominant router now has a thriving ecosystem of open-source, feature-rich, high-performance alternatives.
Our embeddable query planner will hopefully help teams bridge the gap and skip many of the pitfalls we encountered while implementing federation.
Vendors such as Apollo, Grafbase, and ourselves were present, allowing people to get an overview of the most widely adopted solutions today.
Major companies are also investing in building and open-sourcing their own solutions, such as the Kotlin implementation presented by Expedia in their session.
Companies like Booking.com shared their migration story from a monolith to federation.
Federation is no longer tied to a single language — developers from many ecosystems are federating in the languages they love.
The Composite Schema Working Group is steadily making progress on creating a shared specification that vendors and federation users can agree on and build upon, leading us to an interoperable future. Michael gave us a live demo of what to expect in the future.
On top of that, we also saw innovation from companies like Airbnb that reimagine building monoliths in a federated way with Viaduct.
GraphQL Fragments in the spotlight
This year, GraphQL Fragments finally had their moment in the spotlight.
“They are for describing UI component data dependencies, not for re-use!”
Teams are increasingly adopting fragments to build reusable UI components, and lots of best practices were shared. While Meta developers have long relied on this approach — as showcased by Janette Cheng in her session on “How to use Fragments” — we’re thrilled to see it gain traction across the broader community. It was great to hear other companies’ success stories about scaling UI and components with Fragments, such as Gabriel Cura-Castro’s session “Building Federated Component Systems That Scale”, which also brought in the federation aspect.
With Relay, Apollo, and the GraphQL Code Generator client preset, developers now have powerful tooling to build efficient, reusable UI components.
Fullstack Innovation
We all know the veteran clients: Relay and Apollo. Relay showed off new features solving problems at Meta scale, such as how to roll out strict error handling. Apollo is catching up on feature parity with proven patterns like fragment data masking.
But fresh projects are also pushing boundaries:
- Houdini GraphQL has proven itself in the Svelte community, offering an opinionated, end-to-end fullstack GraphQL experience. Alec Aivazis was on stage to share the concepts behind it.
- Isograph, while more controversial, wowed the crowd with its bold ideas — even breaking some established GraphQL syntax. Robert Balicki’s live demo of Isograph was hands-down one of the most entertaining and impressive moments of the conference.
- Graffle, a modular and type-safe GraphQL client, was presented in a hands-on demonstration by Jason.
It’s inspiring to see new projects experimenting and gaining adoption.
Errors and Nullability
The Nullability Working Group is making big strides in improving error handling.
Right now, when you see null in a GraphQL response, it could mean:
- ✅ A field is intentionally null (e.g.,
middleNamedoesn’t exist). - ❌ Something went wrong (resolver error, permissions issue, downstream failure, etc.).
This ambiguity has long been a pain point. Removing it will make GraphQL responses clearer, safer, and easier to work with — for both API designers and client developers.
Different approaches were discussed, and we’re eager to see how community feedback will shape the spec.
Working group veteran Benjie shared how we can further improve in this space.
In addition, Jeff showcased how to model expected errors as part of the GraphQL schema and demonstrated best practices and approaches for designing scalable, future-proof APIs.
Public GraphQL APIs
Everyone is now using persisted documents or trusted documents, with the exception of those adventurous teams tackling the challenge of launching public GraphQL APIs. Whether it is Buffer rebuilding their public API in GraphQL, monday.com tackling the challenge of documenting their API with AI tools, or us building and releasing our own GraphQL API for our Schema Registry and Federation Platform product Hive Console, more and more people are exploring GraphQL as a tool and entry point for third-party API consumers and businesses.
Tools like Pollen help bridge the gap between introspection documentation provided by tools like GraphiQL and handcrafted documentation. The need for better tooling to monitor and analyze API usage is becoming more evident.
New problems are also emerging, such as how to deprecate and remove unused fields over time. In this space, schema registries and analytics platforms like our Hive Console can unleash their true potential. Rick Bijkerk showcased how they automated schema cleanup using Hive Console in his lightning talk.
We are super excited to see more organizations joining the ranks of GitHub, Shopify, and monday.com in the public GraphQL API space.
Closing Thoughts
What a ride!
As always, we’re grateful to be part of this amazing community. GraphQL Conf 2025 was a fantastic celebration of 10 years of progress, collaboration, and innovation.
We can’t wait to see everyone again next year!