Inaccessible vs Inaccessible Type

[smyrick]

Today we have proposed an @inaccessible directive that is available in Apollo Federation

directive @inaccessible on FIELD_DEFINITION | INTERFACE | OBJECT | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION

Indicates that a definition in the subgraph schema should be omitted from the router's API schema, even if that definition is also present in other subgraphs. This means that the field is not exposed to clients at all.

Common use cases for @inaccessible include:

Avoiding composition errors while making staggered updates to a definition that's shared across multiple subgraphs (such as a value type)

Using a private field as part of an entity's @key without exposing that field to clients

---

Applying this directive to a field does above what is described, it hides it from clients. Applying the directive to a type does a couple things:

• It applies the @inaccessible directive to all the fields so they are hidden
• It also applies the hiding logic to all other subgraphs that use and reference this type.
  • This means if one subgraph adds @inaccessible to the definition of some shared entity like type User @inaccessible it removes that entire type from the supergraph

This is currently by design to allow for easier evolution of types with Apollo Federation but do we want to consider adding something that has different logic for types/objects vs fields

directive @inaccessible on FIELD_DEFINITION | ARGUMENT_DEFINITION | ENUM_VALUE | INPUT_FIELD_DEFINITION

directive @inaccessibleObject on INTERFACE | OBJECT | UNION | SCALAR | ENUM | INPUT_OBJECT