Allow empty object types

[benjie]

Merge first:

• Allow empty selection sets #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 Proposal: Do not require query as a root operation type #490

Related:

• Fixes The ability to represent empty objects #568

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	8c40697
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/6a122f4f925e460007248957
😎 Deploy Preview	https://deploy-preview-1228--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[martinbonnin]

+1000

[jerelmiller]

💯

[leebyron]

Notes from meeting:

We should support syntax grammar for {} to clearly define no fields

key motivation is that "a schema minus all deprecated elements is always valid" which today could be not true! For a bunch of reasons but in this case:

type Example {
  onlyField @deprecated
}

this cannot create a valid non-deprecated schema! that's our aim.

Another example: a mutation payload (relay style) that wants to be defined up front as

Specifically important because the LLM-focused subschema generation still has some issues we're working out, and it's unclear that providing type Book {} to the LLM is what we want to do or not.

[martinbonnin]

Looks like we'll need the same for input objects?

[andimarek]

I am not sure this is the right place to comment, but together with the issue about interfaces without fields and interfaces without objects implementing them I am wondering if we should distinguish between valid schemas vs valid and executable schemas.

For example an interface without an implementation is not something I find sensible for a real schema that should be executed but for schema during design it is ok.

[martinbonnin]

an interface without an implementation is not something I find sensible for a real schema that should be executed

@andimarek My preference here would be a lint warning. The spec is already a bit vague on SDL validation (see #1233 (comment)) so we're not really equipped to have executable vs non-executable validation yet.