Namespacing the schema

Have all types and interfaces in the schema be automatically namespaced.

Namespacing the schema avoids naming conflicts, which happens when different owners (eg: different teams in the company, or among 3rd party plugins) use the same name for a type or interface.

For instance, let's say that company "AwesomeWP" has the Tutorials and the Sales team, and both of them create a Product type for the company's GraphQL schema, producing a conflict.

By namespacing the schema, the two types would be automatically converted to AwesomeWPTutorialsProduct and AwesomeWPSalesProduct, avoiding the conflict without having to manually modify the schema, or have the teams interact with each other.

Namespacing the schema permalink

There are 2 levels in which we can define if the schema will be namespaced or not. In order of priority:

1. On the schema configuration permalink

Namespacing the schema for a custom endpoint or persisted query, can be defined through the corresponding schema configuration:

Namespacing, set in the Schema configuration
Namespacing, set in the Schema configuration

2. Default mode, defined in the Settings permalink

If the schema configuration has value "Default", it will use the mode defined in the Settings:

Namespacing in Settings
Namespacing in Settings

Visualizing the namespaced schema permalink

Use the Voyager client to visualize the namespaced schema.

When namespacing is disabled, the WordPress schema looks like this:

Interactive schema
Interactive schema

When it is enabled, it looks like this:

Namespaced interactive schema
Namespaced interactive schema

Querying (non-)namespaced type names permalink

Once namespaced is enabled, types can be queried using both their namespaced and non-namespaced type names. Hence, only queries involving conflicting types need be edited, and not all of them.

For instance, if AwesomeWP's Sales team also has a Discount type, a query asking for this type name still works:

query {
discounts {
...DiscountProps
}
}

fragment DiscountProps on Discount {
price
dateRange
}

Only the conflicting type Product should be updated to AwesomeWPSalesProduct in the query, as to remove any ambiguity:

query {
products {
...ProductProps
}
}

fragment ProductProps on AwesomeWPSalesProduct {
price
dateRange
}

GraphQL spec permalink

This functionality is currently not part of the GraphQL spec, but it has been requested in: