Airbnb and Expedia adopt LLM-generated GraphQL mocks while spec remains unresolved

Expedia’s mockql-rs and Airbnb’s @generateMock solve the same problem, generating realistic mock data for GraphQL fields, with fundamentally different architectures. Expedia’s tool operates as a standalone CLI, intercepting requests and filling annotated fields with LLM-generated data at runtime. This allows a single response to combine live backend data with mock data for unresolved fields, enabling incremental development without waiting for backend resolvers. The trade-off is runtime overhead and dependency on an external LLM, which may introduce latency or cost in high-volume environments like CI pipelines or local development servers.

Airbnb’s approach, by contrast, runs at build time, generating static mock data and typed accessors for use in tests and demos. This eliminates runtime dependencies but requires engineers to regenerate mocks after schema changes, even if the tool preserves manual edits. The build-time model is simpler to integrate into existing workflows but less flexible for dynamic or context-dependent mocking. Both tools use LLMs to fill schema-defined shapes, but Airbnb’s design prioritizes determinism and reproducibility, while Expedia’s prioritizes immediacy and adaptability.

The GraphQL Foundation’s RFC introduces a third design, treating mocks as first-class artifacts validated by clients and test suites. Unlike the other two, it does not mandate LLM generation, instead positioning it as one of several possible strategies. The RFC’s approach is more prescriptive about validation and drift detection, which could reduce maintenance burden but requires deeper client integration. The lack of consensus on the @mock directive, whether it applies to fields or operations, and whether it triggers runtime or build-time generation, creates friction for teams evaluating these tools.

The fragmentation reflects broader tensions in GraphQL tooling: runtime flexibility versus build-time predictability, and vendor-specific solutions versus spec-driven standardization. For engineers, the choice between these tools hinges on workflow priorities. Teams needing rapid prototyping or incremental backend development may prefer Expedia’s runtime model, while those focused on test stability or CI efficiency may lean toward Airbnb’s build-time approach. The unresolved spec means no tool is a drop-in replacement for another, and migrating between them could require rewriting mocks or retooling pipelines.

The reliance on LLMs for mock data generation introduces its own risks. While models excel at filling predefined schema shapes, they may produce inconsistent or unrealistic data, particularly for complex or nested fields. Expedia’s tool mitigates this by allowing hints (e.g., “5 most popular nearby restaurants”), but the quality of generated data still depends on the model’s training and prompt engineering. Teams adopting these tools must weigh the convenience of automated mocking against the need for manual review or post-processing to ensure data realism and edge-case coverage.