Skip to main content
Back to Dev generators

Dev

Mock GraphQL Schema Generator

Used by developers, writers, and creators worldwide.

A mock GraphQL schema generator solves the blank-page problem when you need valid SDL before your backend exists. Enter an entity name — "Product", "Invoice", "BlogPost" — set a field count, and the tool produces a complete schema: a typed object, CreateInput and UpdateInput types, single-item and list queries, plus create, update, and delete mutations wired into the root. No manual boilerplate, no hunting for SDL syntax. Frontend teams use this to unblock themselves immediately. Paste the output into Apollo Server, GraphQL Yoga, or a .graphql file and start querying in minutes. Field names are realistic, and scalars cover the spread — ID, String, Int, Boolean — that real schemas rely on.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Type your entity name in singular PascalCase (e.g., "Invoice") into the Entity Name field.
  2. Set the Number of Fields slider to how many properties the type should have, between 3 and 15.
  3. Click Generate to produce the complete SDL schema with types, inputs, queries, and mutations.
  4. Copy the output and paste it into your .graphql file, typeDefs string, or GraphQL Playground schema editor.
  5. Refine field names and types manually, then wire up resolvers to make the schema functional.

Use Cases

  • Spinning up a typeDefs block in Apollo Server before any resolvers are written
  • Generating a plausible SDL fixture for Jest or Vitest unit tests on a GraphQL client
  • Bootstrapping a Postman GraphQL collection with a realistic schema for API demos
  • Creating a Hasura custom action schema without writing SDL from scratch
  • Building SDL examples for workshop exercises covering input types and mutation conventions

Tips

  • Name your entity after a real domain object ("Subscription", "Shipment") to get field names that read as plausible in demos.
  • Generate two related entities separately — e.g., "Order" and "Customer" — then manually add a relationship field to connect them.
  • If you need DateTime fields, generate the schema, then swap any String field that represents a date to a custom scalar DateTime after pasting.
  • Use the output directly in Apollo Sandbox or GraphQL Playground to auto-generate interactive documentation before writing a single resolver.
  • For teaching, generate the same entity with 4 fields and again with 10 to show how input types scale and why field discipline matters.
  • Pair with a mock data generator tool to populate resolver return values that match the generated types, giving you a fully demoable API fast.

FAQ

how do I use a custom entity name and get correct query and mutation names

Type your entity name in singular PascalCase — "Order", "BlogPost", "LineItem" — into the Entity Name field, set a field count, and click Generate. The tool derives query names (product, products), mutation names (createProduct, updateProduct, deleteProduct), and input types (CreateProductInput) directly from that name, so correct casing produces clean, conventional SDL you can paste straight into Apollo Server or a .graphql file.

is the generated schema valid sdl I can actually run with apollo server

Yes. The output follows standard GraphQL Schema Definition Language compatible with Apollo Server, GraphQL Yoga, and Mercurius — drop it into a typeDefs string or a .graphql file without modification. For production, review non-null constraints and add custom scalars like DateTime or JSON, but the structure and naming conventions are spec-compliant from the start.

what queries and mutations does the generator include by default

You get two queries: a single-item lookup (e.g., product(id: ID!): Product) and a list query (products: [Product!]!). On the mutation side there are three operations: createProduct accepts a CreateProductInput, updateProduct takes an ID plus UpdateProductInput, and deleteProduct takes an ID and returns a Boolean. All five operations are wired into the root Query and Mutation types automatically.