Allow empty object types

At a glance

• Identifier: #1228
• Stage: RFC 1 / Proposal
• Champion: @benjie
• Latest activity: Top comment edited on 2026-07-02
• Spec PR: https://github.com/graphql/graphql-spec/pull/1228
• Related:
  • #568

Spec PR description

Merge first:

• #1227

Since 2015 we've always required an object type to define at least 1 field. As we continue to explore GraphQL's position in the new AI-world, we realise that we need schema subsets that represents part of a larger interface, in these cases it's sometimes useful to leave in type references without including full definitions of those types:

type Query {
  topAuthors: [Author!]
}
type Author {
  name: String!
  salesVolume: Int
  averageRating: Float
  topBooks: [Book!]
  mediaCoverage: [Article!]
  recentPublishers: [Publisher!]
}
type Book {}
type Article {}
type Publisher {}

Here the AI can see a basic schema it can write queries against, but it can also ask to expand the parts of the schema that are relevant to its interests - e.g. books or articles or publishers - without wasting context on things it doesn't care about.

We can make a schema like this valid by including at least one field on each of these types, but it's hard for a tool to know which field(s) to include, and not including fields makes it much more obvious to the LLM that the schema is partial. Making this partial schema itself valid would be helpful for tooling.

AI aside:

• This is also very useful for mutation payloads where no obvious value exists to return yet but we may wish to expand in future. Currently type MyMutationPayload { success: Boolean! } is used as a workaround, but it's messy.
• This is also very useful for schema evolution - it allows you to create a type before you know what it will contain, and allows you to deprecate all fields of a type without the schema being invalid.
• This also enables mutation-only schemas whilst still supporting introspection #490

Related:

• Fixes https://github.com/graphql/graphql-spec/issues/568