Skip to main content

Schema Fragments

At a glance

Timeline


RFC: Schema Fragments

Problem

When writing large schemas, there is no way to reuse similar fields between ObjectTypeDefinition(s) and InputValueDefinition(s). One can use interfaces to enforce that particular fields are implemented, though this doesn't really help, as a schema creator I still have to repeat X fields on X amount of types.

Below I have Users(s) and Post(s) and where both types have the following properties; id, createdAt and updatedAt:

type User {
id: ID # Repeated
createdAt: DateTime # Repeated
updatedAt: DateTime # Repeated
name: String
}

type Post {
id: ID # Repeated
createdAt: DateTime # Repeated
updatedAt: DateTime # Repeated
content: String
}

Notice how the three properties are repeated.

As mentioned, you can use interfaces here, so for example a BaseInterface that contains the properties, and then this is implemented on each type:

interface BaseInterface {
id: ID # Repeated
createdAt: DateTime # Repeated
updatedAt: DateTime # Repeated
}

type User implements BaseInterface {
id: ID # Repeated
createdAt: DateTime # Repeated
updatedAt: DateTime # Repeated
name: String
}

type Post implements BaseInterface {
id: ID # Repeated
createdAt: DateTime # Repeated
updatedAt: DateTime # Repeated
content: String
}

However, this isn't helpful at scale because your still repeating each field.

Solution

Enable the usage of fragments on ObjectTypeDefinition(s) and InputValueDefinition(s) to reduce the repetition of common fields.

Below I have Users(s) and Post(s) and where both types have the following properties; id, createdAt and updatedAt. The listed properties are only defined once and I use the fragment spread syntax to apply them to each type:

fragment BaseInterface on ObjectTypeDefinition {
id: ID
createdAt: DateTime
updatedAt: DateTime
}

type User {
...BaseInterface
name: String
}

type Post {
...BaseInterface
content: String
}

Implementation

I assume that the GraphQL parser would need to be adapted to allow the usage of fragments on the fields, and then I see it being something that your tool should implement similar to how interfaces are enforced.