Mock GraphQL Schema Generator

GraphQL mock schemas: SDL, types, and parallel front-end development

GraphQL is a query language and runtime for APIs, designed by Lee Byron and colleagues inside Facebook in 2012 to solve the over-fetching and under-fetching problems of REST. It was open-sourced in 2015 and is now governed by the GraphQL Foundation under the Linux Foundation. Instead of multiple round-trips to different endpoints, a single GraphQL query describes exactly what fields the client needs, and the server returns a JSON tree that matches the shape of the query. A mock schema is a schema with placeholder resolvers that return fake but well-typed data, letting front-end engineers iterate without waiting for the back-end implementation to land.

This generator scaffolds a minimal SDL skeleton for a resource; the reference below covers schema-first vs code-first workflows, the type system, the major mocking tools, and the production patterns that distinguish a serious GraphQL API from a tutorial example.

Schema-first vs code-first

Two philosophies dominate. Schema-first declares the API contract in SDL (Schema Definition Language) first, then wires resolvers to match — used by Apollo Server, GraphQL Yoga, and most JavaScript stacks. Code-first generates the SDL from typed classes or functions — used by TypeGraphQL, Pothos, NestJS GraphQL, and Hot Chocolate (.NET). Schema-first keeps designers and back-end engineers aligned around a single document; code-first removes drift between types and resolvers but hides the schema until build time.

type Query {
  user(id: ID!): User
  users(limit: Int = 10): [User!]!
}
type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}
type Post {
  id: ID!
  title: String!
  author: User!
}

The type system

• Scalars: Int, Float, String, Boolean, ID. Custom scalars (DateTime, JSON, UUID) are common via graphql-scalars.
• Object types: domain entities with named fields, the bread and butter of any schema.
• Enums: closed sets like enum Role { ADMIN USER GUEST }.
• Input types: argument bundles for mutations (input CreateUserInput { ... }).
• Interfaces and unions: polymorphism — interface Node { id: ID! } or union SearchResult = User | Post.
• Lists and non-null: [Post!]! means a non-null list of non-null posts. Rich nullability is one of GraphQL's biggest wins over REST.

Mocking strategies and tools

There are three common strategies depending on how realistic the mock needs to be:

• Random per call: each query returns fresh random data. Easiest setup — use Apollo Server with mocks: true, GraphQL Faker, or @graphql-tools/mock addMocksToSchema.
• Deterministic per ID: seed the PRNG by the queried ID so the same lookup returns the same payload across reloads — ideal for Storybook and visual regression.
• Persisted state: keep mocks in IndexedDB / LocalForage so create/update/delete flows behave like a real backend. MSW (Mock Service Worker) intercepts requests at the network layer and is the modern default for front-end test suites.

For Storybook fixtures, deterministic mocks are essential — a random avatar URL breaks pixel-diff tests. For demo environments, persisted mocks let product managers click through end-to-end flows without a real database.

REST vs GraphQL and production patterns

GraphQL solves over-fetching (REST returns more fields than needed) and under-fetching (REST forces multiple round-trips). The cost is a new class of problems: the N+1 query problem (a parent resolver loads N children one by one) is mitigated by DataLoader, a batching cache by Facebook. Authorization moves from URL-level (REST middleware) to field-level (resolver guards). Pagination should use the Relay cursor spec (edges, pageInfo, cursor) instead of offset/limit. Errors are increasingly modelled as union types (the Result pattern) so clients handle them with the same type-safety as success cases. For microservices, Apollo Federation and GraphQL Mesh compose subgraphs into a single supergraph.

FAQ

Does GraphQL replace REST? No — it complements it. Many shops keep public REST APIs and add a GraphQL gateway for internal clients and partners. Both can coexist behind the same load balancer.

Does mocking really help parallel work? Yes. Once the SDL is agreed, front-end and back-end teams can develop against the same contract independently. Contract tests (e.g. graphql-codegen against the SDL) catch drift before integration.

Which mocking tool should I pick? For unit tests inside a JS app, MSW. For a fake backend during local dev, Apollo Server with mocks: true. For exploring a public schema, GraphQL Faker. For Storybook, custom mocks per story.

Where do I learn the official spec? graphql.org/learn for the tutorial and spec.graphql.org for the formal grammar. The Guild maintains a huge ecosystem of tooling (Codegen, Mesh, Yoga, Inspector).