Working with generic types

In this section of the documentation, we cover the fundamentals that are behind a lot of the magic that goes into making DataObject types work. We'll create some types that are not based on DataObjects at all, and we'll write some custom queries from the ground up.

This is useful for situations where your data doesn't come from a DataObject, or where you have very specific requirements for your GraphQL API that don't easily map to the schema of your DataObject classes.

Just because we won't be using DataObjects in this example doesn't mean you can't do it - you can absolutely declare DataObject classes as generic types. You would lose a lot of the benefits of the DataObject model in doing so, but this lower level API may suit your needs for very specific use cases.

You are viewing docs for silverstripe/graphql 4.x. If you are using 3.x, documentation can be found in the GitHub repository

Creating a generic type

Creating a type that doesn't map to a DataObject

Building a custom query

Add a custom query for any type of data

The resolver discovery pattern

How you can opt out of mapping fields to resolvers by adhering to naming conventions

Adding arguments

Add arguments to your fields, queries, and mutations

Adding pagination

Add the pagination plugin to a generic query

Adding descriptions

Add descriptions to just about anything in your schema to improve your developer experience

Enums, unions, and interfaces

Add some non-object types to your schema

Edit on Github

Working with generic types#