SDL stands for Schema Definition Language, the human-readable syntax GraphQL uses to declare types, fields, queries, and mutations. Servers like Apollo and graphql-js parse SDL into an executable schema.

What does the exclamation mark mean?

A trailing exclamation mark marks a field as non-null, meaning the API guarantees a value. Without it the field is nullable and may return null in a response.

What are input types for?

Mutations cannot take object types as arguments, so GraphQL uses input types to bundle arguments. The builder emits a matching input type per entity for create and update operations.

Do I get an ID field automatically?

Yes. Each generated object type includes an id field of type ID, which is the conventional non-null primary key GraphQL clients expect for caching and refetching.

How do I use the generated mutations?

Each entity gets create, update, and delete mutations referencing its input type. You still write resolvers, but the signatures and argument shapes are defined for you so the contract is fixed.

What is the GraphQL Schema Builder?

Takes entity names and field definitions and outputs a complete GraphQL Schema Definition Language file with object types, input types, a Query type, and CRUD Mutation fields ready to paste into your server. It runs free in your browser on Gera Tools, with nothing uploaded.

GraphQL Schema Builder

Name: GraphQL Schema Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Generate a GraphQL schema fast

A GraphQL schema is the contract between client and server. Writing the SDL by hand means repeating the same type, input, Query, and Mutation boilerplate for every entity. This builder takes a compact list of entities and fields and produces a complete, valid schema you can drop straight into your server’s typeDefs.

How it works

Each entity block becomes an object type with the fields you list plus a non-null id: ID!. Fields are parsed as name: Type, where a trailing ! keeps the non-null marker and [Type] denotes a list. When input types are enabled, every entity also gets a matching input type with the same fields minus id, since clients supply ids only for updates. The Query type gains a singular field that takes an id and a plural list field per entity. With mutations enabled, each entity gets create, update, and delete fields whose arguments reference the generated input type, following the standard CRUD convention.

Tips and example

Write one entity per block, for example a User type with name: String! and email: String!, then a Post type with title: String! and author: User. Reference other entity names directly to build relationships. Use [Post!]! for a non-null list of non-null posts. After generating, paste the SDL into Apollo Server’s typeDefs and write resolvers matching the field names.

What to do after generating the SDL

Connect it to your server

In an Apollo Server setup you pass the SDL directly to the typeDefs property:

const server = new ApolloServer({
  typeDefs,      // your generated SDL string
  resolvers,     // your resolver map
});

In graphql-js you call buildSchema(typeDefs) to convert the SDL to an executable schema object.

Write matching resolvers

The generated schema names every query and mutation field. Your resolver map must mirror those names exactly. For example, if the schema contains type Query { user(id: ID!): User }, your resolver must be:

const resolvers = {
  Query: {
    user: (_, { id }) => findUserById(id),
  },
};

Mismatched names between the SDL and the resolver map are the most common source of null responses — the field resolves but returns undefined because the resolver key doesn’t match.

Code generation

For TypeScript projects, pass the SDL to GraphQL Code Generator to produce typed resolver signatures, typed React hooks (with Apollo Client or urql), and an introspection file for IDE tooling. The generated types will name fields exactly as in the SDL, so changes to the schema automatically surface as TypeScript errors in your resolver and client code.

Non-null design decisions

GraphQL fields are nullable by default; ! makes them non-null. A good rule of thumb: IDs and required identifiers are always !, most data fields are nullable to allow partial responses and future schema evolution without breaking changes. Over-annotating with ! makes your API brittle — any future scenario where a value might genuinely be absent becomes a breaking change requiring client updates.