GraphQL

Three Teams, One Problem: LLMs Fill GraphQL Mock Gaps

Three teams are now solving the same problem in different ways.

3 min readInfoQ
Three Teams, One Problem: LLMs Fill GraphQL Mock Gaps

When Expedia Group open-sourced mockql-rs, a Rust CLI that fills @mock-annotated GraphQL fields with LLM-generated data at request time, it landed in a space that was already getting crowded. Airbnb shipped @generateMock in April. The GraphQL Foundation has had an RFC open since February. Three serious efforts, all attacking the same fundamental problem: writing realistic mock data by hand is tedious, brittle, and increasingly unnecessary when a language model can generate it on the fly.

What makes this moment worth pausing on is not the technical cleverness of any single implementation. It is the fact that two of these approaches use the same directive name, @mock, with incompatible semantics. That is a small detail with large consequences. If you are building a GraphQL schema today, you have no way of knowing whether a @mock directive means what Airbnb means, what Expedia means, or what the eventual spec might say. The ecosystem is moving faster than the standards body, and that gap is not neutral. It is a tax on every developer who adopts the wrong assumption.

We would tell any reader who is watching this unfold to focus less on which tool wins and more on what the delay signals. The GraphQL Foundation RFC opened in February. It is now late summer. The spec is still lagging. Meanwhile, two major travel companies have shipped production tools that work today. That is not a criticism of the foundation. It is a reflection of how standards work in practice: they consolidate patterns, they do not create them. The pattern here is clear, and the spec will eventually catch up. But the window between innovation and standardization is exactly where teams get stuck with incompatible choices.

There is a useful parallel in how language models are reshaping adjacent infrastructure. Look at how Exploring Paragraph Structure: How LLMs Navigate Token Space describes the internal geometry of token spaces, or how Perplexity Transforms Search with CobbleDB, Achieving 5x Faster Queries shows a company rebuilding core infrastructure around model-driven behavior. The through line is the same: we are moving from deterministic, hand-authored data to generative, model-driven defaults. Mocking is just the first place this becomes obvious because it is low-stakes. No one loses money on a bad mock. But the pattern will not stop there. Once you trust a model to generate your test data, you start asking why it cannot generate your schema, your queries, or your access policies.

The practical takeaway for our readers is direct: do not wait for the spec to tell you how to think about this. Evaluate the Expedia and Airbnb implementations on their merits, but design your systems so the mocking layer is swappable. The directive name collision is a warning sign. It tells you that whatever you adopt today may be a compatibility liability tomorrow. The teams that win here are not the ones who pick the right library. They are the ones who keep their data layer abstract enough to survive the inevitable convergence. Watch whether the GraphQL Foundation responds with a unified directive or lets the ecosystem fragment. That decision will tell you more about the future of GraphQL tooling than any single release.

From InfoQ

Expedia Group has open-sourced mockql-rs, a Rust CLI that fills @mock-annotated GraphQL fields with LLM-generated data at request time. It follows Airbnb's @generateMock in April and a GraphQL Foundation RFC opened in February. All three solve the same problem with different architectures, and two use the same directive name with incompatible semantics.

Read the original at InfoQ