SubGraph plugin
A plugin for creating sub-selections of your graph. This allows you to use the same code/types for multiple variants of your API.
One common use case for this is to share implementations between your public and internal APIs, by only exposing a subset of your graph publicly.
Usage
Install
Setup
Options on Types
- subGraphs: An optional array of sub-graph the type should be included in.
Object and Interface types:
- defaultSubGraphsForFields: Default sub-graph for fields of the type to be included in.
Options on Fields
- 
subGraphs: An optional array of sub-graph the field to be included in. If not provided, willfallback to: - defaultForFieldsif set on type
- subGraphsof the type if- subGraphs.fieldsInheritFromTypeswas set in the builder
- an empty array
 
Options on Builder
- subGraphs.defaultForTypes: Specifies what sub-graph a type is part of by default.
- subGraphs.fieldsInheritFromTypes: defaults to- false. When true, fields on a type will default to being part of the same sub-graph as their parent type. Only applies when type does not have- defaultForFieldsset.
Usage
Missing types
When creating a sub-graph, the plugin will only copy in types that are included in the sub-graph, either by explicitly setting it on the type, or because the sub-graph is included in the default list. Like types, output fields that are not included in a sub-graph will also be omitted. Arguments and fields on Input types can not be removed because that would break assumptions about argument types in resolvers.
If a type that is not included in the sub-graph is referenced by another part of the graph that is included in the graph, a runtime error will be thrown when the sub graph is constructed. This can happen in a number of cases including cases where a removed type is used in the interfaces of an object, a member of a union, or the type of a field argument.