Expedia Group has released mockql-rs, a Rust command-line tool that uses large language models to create GraphQL mock responses on the fly, marking the third public effort in six months to solve the same development challenge. The release follows Airbnb's @generateMock directive in April and a GraphQL Foundation request for comments opened in February. All three projects arrived at notably different technical designs, and two employ the same directive name to accomplish different tasks.
The Expedia tool operates as a standalone process between client and server. Developers mark fields with @mock and an optional hint, and the software parses and validates the operation against the schema using apollo-compiler, splits annotated fields from actual ones, sends real fields upstream, prompts the model with the operation and a subset schema, then combines both into one response. A single response can deliver live backend data alongside generated content for a field whose resolver doesn't yet exist. Expedia built a CLI instead of an SDK because any test runner, CI job or build script can execute a process, avoiding a client-library dependency. In one example query for trip details, the property name and address came from the backend while restaurant recommendations—title, description and distance—were model output, both carrying equal authority in the same payload with nothing marking which is which.
According to Samuel Vazquez, a software engineer at Expedia Group, the approach inverts the usual failure mode with generative tooling: models struggle at inventing shapes but excel at filling them in, and a schema provides a bounded shape for free. The alternative, as his post describes it, is a developer hand-typing a two-hundred-line JSON fixture that the next morning's schema change invalidates. The shared premise across all three implementations is that a GraphQL selection set already functions as a specification. Airbnb's approach runs at build time instead, processing its @generateMock directive during code generation, emitting both a JSON file of mock data and typed accessor functions for demo apps, snapshot tests and unit tests, with the generator deliberately preserving engineers' manual edits on subsequent runs. The RFC takes a third position, defining @mock on operations rather than fields with a name argument selecting between named responses, and requiring that a conforming client return a mock without issuing any network request.
The difference matters more than the syntax, the report notes. The RFC requires clients to detect when a mock response has drifted out of validity for its operation and force corrective action, and states that mocks must be validated as part of the application test suite. Expedia's generated data is produced fresh on each run, delivering contextual coherence but not the repeatability that a snapshot test depends on, and neither post addresses what non-deterministic fixtures mean for continuous integration. The RFC also anticipates the agent workflow directly, recommending that implementers ship an Agent Skill so that coding agents can add or modify mock variants conversationally, placing mock management alongside the other repository conventions agents are being taught to operate. For teams weighing adoption, the standards position is the caveat: the RFC remains at Stage 0, described as a strawman with no champion listed, the earliest point in the GraphQL specification process and no guarantee of progression, and Expedia's implementation already diverges from it on directive placement, argument name and network behaviour, so a team standardising on @mock today is standardising on one vendor's reading of a name the specification also claims. The more durable observation is why this pattern surfaced in GraphQL rather than REST: schema-shaped output is exactly the constraint that makes generated data usable rather than plausible-looking noise, and it's also what allows a tool to detect when the generated data has stopped matching the query, though whether that becomes a specification or three incompatible implementations is currently an open question. The race to define mocking semantics before any standard emerges suggests teams will need to choose carefully between deterministic build-time fixtures and contextual runtime generation, knowing that either path may require rework if the GraphQL Foundation eventually ships a specification. For now, the architectural choice between repeatability and relevance remains a trade-off developers must navigate without official guidance.