GraphQL features a type system (see https://graphql.org/learn/schema/) which is independent of a particular implementation language. Types are written in a special formal language, the Schema Definition Language (SDL). The set of types defined with this SDL is then collectively called the GraphQL schema.

The schema essentially defines what data can be queried from the GraphQL server. Therefore, the GraphQL schema is one way to restrict the information a possible client can retrieve from the Headless Server. Another way would be to use a different CoreMedia CMS user with a different set of rights.

Each query is validated against the schema before query execution, any query that fails this validation is rejected by the Headless Server.

A GraphQL schema for a subset of the CoreMedia Blueprint content model is defined in the file content-schema.graphql. In this schema file, the GraphQL query root type Query is defined and contains a field content of type ContentRoot. This root object supports CoreMedia CMS content repository access. It is implemented by the Spring bean content of class ContentRoot. Further content fields can be added to the GraphQL schema. These must then be implemented either by a @fetch directive (see section Section 4.3, “The @fetch Directive”), or by subclassing the ContentRoot class. In the latter case, an instance of the new subclass must replace the ContentRoot instance in the Spring configuration.

The query root type is extensible by adding Spring beans with the qualifier QueryRoot. This is used in the eCommerce integration module to add a new query root field commerce, as described in Chapter 7, eCommerce Extension.

A GraphQL schema for the Headless Server may be split into several files. So, additional GraphQL types and interfaces can either be added to the schema by extending the file content-schema.graphql, or by adding more GraphQL schema resource files with the name pattern *-schema.graphql to the Java resources folder. During startup, the Headless Server looks for files which follow the location pattern in the classpath. These are then merged together, yielding the complete schema.

Further adapters (Section 4.8, “Adapter”), model mappers (Section 4.5, “Model Mapper”), filter predicates (Section 4.6, “Filter Predicates”), or GraphQL scalar types can be defined as Spring beans in CaasConfig.java, or by adding a new Spring configuration class.

All these extensions can be made within the headless-server-base module within the blueprint workspace. However, a better practice is to add a new Maven module with its own Spring configuration and schema resource file. This separates your extensions from future changes within the headless-server-base module. Again, the eCommerce integration module described in Chapter 7, eCommerce Extension may serve as an example.