About This Interview
This is a special interview between WunderGraph CEO Jens Neuse and GraphQL thought leader Benjie Gillam, member of the GraphQL Technical Steering Committee (GraphQL Foundation) and the creator of Grafast.
Benjie is one of the most respected voices in the GraphQL ecosystem. Through his work on Graphile and his ongoing contributions to the GraphQL spec, Benjie has played a key role in shaping how modern GraphQL systems are built and scaled.
In this conversation, recorded live at API Days Paris 2025, Benjie shares his thoughts on a new approach we’ve developed to reimagine schema design: the Fission algorithm. Fission, a key component of WunderGraph Hub, allows users to design APIs from requirements and automatically derive composable subgraphs.
Key Topics Covered
- Benjie's thoughts on WunderGraph Hub, Fission, and client-focused schema design
- Designing APIs starting from “dream queries” and real frontend needs
- Involving non-technical stakeholders in GraphQL schema and product decisions
- Making schema design more visual and collaborative across teams
- Governance challenges in large GraphQL systems (naming, consistency, ownership)
- The importance of fragments and component-driven data modeling in GraphQL
- Grafast and rethinking GraphQL execution beyond resolvers and DataLoader
Who Should Watch
This episode is ideal for:
- Platform and infrastructure engineers
- API and GraphQL architects
- Backend and frontend engineers working with Federation
- Teams struggling with schema ownership and governance
- Organizations scaling GraphQL across multiple teams
- Developers interested in client-driven API design and modern schema workflows
GraphQL was always client-first. Fission applies that to the whole stack.
Benjie’s first reaction to Fission was that it extends something GraphQL already believes about itself.
GraphQL itself is always designed to be used by the client. It’s very much a client-focused technology. What Fission does, from what I understand, is it takes that same ethos to the whole super graph subgraph problem and essentially says, what do I need on the front end?
He described it as a way to push the problem down into subgraphs and microservices, but scoped, so each team only has to deal with the part that’s relevant to them.
You can focus on just the bit that you care about, you can scope it out. The design of it was fantastic.
He also noted that being able to see code owners and the people responsible for each section was something he found genuinely useful.
For a written take on putting the consumer-facing API first in federation, see GraphQL Federation Was Built Backwards.
The easy problems are naming conventions. The harder ones are about what data even means.
When Jens asked about the biggest pain points in schema design and governance, Benjie drew a distinction between the problems that are straightforward to solve and the ones that aren’t.
At the larger end of the scale, with many teams, different languages, and different conventions, you get surface-level inconsistencies like snake_case versus camelCase. Those are fixable with tooling.
There’s more insidious problems than that. Such as like name versus first name, last name, where they may be inconsistent in different parts of the system because different people have different outlooks on what that data should be.
The reason Hub resonated with him was that it addresses this second category, not by enforcing rules, but by getting the right people into the conversation without pulling in everyone at once.
I really like the idea with Hub that it essentially gives you this ability to pull in the kind of people who would be involved in those decisions and help make it consistent, but without having to bring in everyone on every team.
He added that keeping a schema consistent is easy when you’re the only person working on it. The challenge is maintaining that as you scale.
We’ve written about the federation collaboration bottleneck in The Missing Layer in GraphQL Federation, and about day-to-day schema quality in 10 Principles for Designing Good GraphQL Schemas.
Non-technical stakeholders can follow a type definition. They get lost in the interconnections.
Jens asked whether tools like Hub could make schema design more accessible to non-technical personas (designers, product owners, front end developers). Benjie’s answer was that GraphQL is approachable up to a point.
GraphQL is fairly approachable from a simple type definition perspective. They can understand if you’ve got type user and it’s got a first name and a last name, and those are strings. That’s fine, that’s easy.
But once the graph gets complex, non-technical people start to struggle.
Once they start having to think more deeply about all the interconnections, I think the non-technical folks quite quickly can get lost in the complexity.
He noted that filtering and toggling visibility of different parts of the graph (something shown in our Introducing Fission demo) can make it much more approachable. The ability to hide what isn’t relevant is part of what makes Hub’s approach work for a broader range of people.
Starting from the query was the original idea of GraphQL.
Jens referenced a blog post by Mark Larah from Yelp in 2020 that first introduced the “dream query” workflow, and asked whether starting schema design from the query makes sense. Benjie’s answer was immediate. We unpack the same workflow in The Dream Query: Consumer-First GraphQL API Design. For how Fission carries that idea across subgraphs, see GraphQL Federation Was Built Backwards.
Oh, of course. GraphQL was always designed to be a client-focused language. So yeah, it absolutely makes sense to start there.
He was careful to note that client-first doesn’t mean dictated by a single client: your mobile app shouldn’t define the schema and force the web client to work around it. The schema should be motivated by the needs of the full range of clients.
What’s in your schema should be the things that you want your clients to consume.
He also connected this to fragments. When GraphQL is being used well, fragments sit next to components and describe exactly the data that component needs. That, he said, is what removes the need for separate client-side models.
You’re putting fragments next to your components, and they are describing the data that is needed exactly for that component. You don’t really need a client-side model.
Jens took that further, describing a direction where nested UI boxes become named fragments, which could generate not just a schema but an entire client structure, with data masking, component names, and enough context to give an LLM a rich picture of the UI being built. Benjie called the idea compelling, including surfacing those components in Storybook with sensible data.
Grafast: plan first, then process the data
Benjie’s own main project is Grafast, a new planning and execution engine for GraphQL, aimed at monolithic schemas and subgraphs rather than supergraph orchestration.
The starting point is a critique of resolvers. He’s direct about it.
Resolvers aren’t great. They introduce the n plus one problem. We then try and solve that with DataLoader. But that’s not actually a very good solution. It results in a whole bunch of other problems, and it just doesn’t solve the problem as well as it could be done.
Grafast’s answer is to change when the work happens. Instead of resolving fields on demand as requests come in, Grafast plans the execution ahead of time, before any data arrives, and then processes the data according to that plan.
Let’s plan out what needs to happen and then just process the data afterwards.
He’s also active on the GraphQL spec and a range of other open source work in the ecosystem. When asked if Grafast had a slogan, he didn’t hesitate.
Don’t do it half-assed. Do it Grafast.
Additional Resources
Read next
