Federation-specific GraphQL directives

Apollo Federation defines a collection of directives that you use in your subgraph schemas to enable certain features.

Importing directives

To use federated directives in a Federation 2 subgraph schema, apply the @link directive with the following format to the schema type:

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        import: ["@key", "@shareable"])

You can apply this directive to your existing schema declaration if you have one, or to a new extend schema declaration (as shown above).

Modify the import array to include whichever federated directives your subgraph schema uses. The example above imports the @key and @shareable directives (which are used most commonly).

Renaming directives

If an imported directive's default name matches one of your own custom directives, you can rename the imported directive with the following syntax:

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        import: [{ name: "@key", as: "@primaryKey"}, "@shareable"])

This example subgraph schema uses @primaryKey for the federated directive usually named @key.

Namespaced directives

If you don't import a particular directive from a linked spec, you can still use that directive in your subgraph schema. However, that directive is namespaced with a prefix:

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        import: ["@key"])
4

5
type Book @federation__shareable {
6
  title: String!
7
}

In the example above, @shareable is not imported from the federation spec. Therefore, it is available as @federation__shareable.

The default namespace prefix for a @linked directive is the name of its associated specification (indicated by the penultimate component of url), plus two underscores (__). For Apollo Federation directives, this prefix is federation__.

You can customize a particular specification's namespace prefix by providing the as argument to @link:

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        as: "fed")
4

5
type Book @fed__shareable {
6
  title: String!
7
}

As shown, custom namespace prefixes also end in two underscores.

@link

1
directive @link(
2
  url: String!,
3
  as: String,
4
  for: link__Purpose,
5
  import: [link__Import]
6
) repeatable on SCHEMA

Links definitions from an external specification to this schema. Every Federation 2 subgraph uses the @link directive to import the other federation-specific directives described in this article (see the syntax in Importing directives).

For more information on @link, see the official spec.

Managing types

@key

1
directive @key(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE

Designates an object type as an entity and specifies its key fields (a set of fields that the subgraph can use to uniquely identify any instance of the entity).

1
type Product @key(fields: "id") {
2
  id: ID!
3
  name: String!
4
  price: Int
5
}

You can apply multiple @key directives to a single entity (to specify multiple valid sets of key fields), if your subgraph library supports repeatable directives:

1
type Product @key(fields: "upc") @key(fields: "sku") {
2
  upc: ID!
3
  sku: ID!
4
  name: String
5
}

To check whether your subgraph library supports repeatable directives, see the repeatable @key item in Federation-compatible subgraph implementations.

Arguments

@extends

1
directive @extends on OBJECT | INTERFACE

Indicates that an object or interface definition is an extension of another definition of that same type.

This directive is for use with GraphQL subgraph libraries that do not support the extend keyword. Most commonly, these are subgraph libraries that generate their schema programmatically instead of using a static .graphql file.

Managing shared fields

@shareable

1
directive @shareable on FIELD_DEFINITION | OBJECT

Indicates that an object type's field is allowed to be resolved by multiple subgraphs (by default in Federation 2, object fields can be resolved by only one subgraph).

1
type Position {
2
  x: Int! @shareable
3
  y: Int! @shareable
4
}

If applied to an object type definition, all of that type's fields are considered @shareable:

1
type Position @shareable {
2
  x: Int!
3
  y: Int!
4
}

If a field is marked @shareable in any subgraph, it must be marked as either @shareable or @external in every Federation 2 subgraph that defines it.

If a field is included in an entity's @key directive, that field is automatically considered @shareable and the directive is not required in the corresponding subgraph(s).

See also Value types in Apollo Federation and Resolving another subgraph's field.

@inaccessible

1
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 gateway'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

type Position @shareable {
  x: Int!
  y: Int!
  z: Int! @inaccessible
}

type Position @shareable {
  x: Int!
  y: Int!
  # Subgraph is not yet updated
}

Often when you add a field to a value type in one subgraph, composition fails because that field isn't resolvable in other subgraphs. With @inaccessible, you can preserve composition while adding the field to your remaining subgraphs. When the rollout is complete, you can remove the directive and begin using the field.

An @inaccessible field or type is not omitted from the supergraph schema, so the graph router still knows it exists (but clients can't include it in operations). This is what enables the graph router to use an @inaccessible field as part of an entity's @key when combining entity fields from multiple subgraphs.

If a type is marked @inaccessible, all fields that return that type must also be marked @inaccessible. Otherwise, a composition error occurs.

For more information, see Using @inaccessible.

@override

1
directive @override(from: String!) on FIELD_DEFINITION

Indicates that an object field is now resolved by this subgraph instead of another subgraph where it's also defined. This enables you to migrate a field from one subgraph to another.

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Products")
}

In the example above, we're migrating the Product.inStock field from the Products subgraph to the Inventory subgraph. The composed supergraph schema indicates that Product.inStock is resolved by the Inventory subgraph but not the Products subgraph, even though the Products subgraph also defines the field.

You can apply @override to a @shareable field. If you do, only the subgraph you provide in the from argument no longer resolves that field. Other subgraphs can still resolve the field.

Only one subgraph can @override any given field. If multiple subgraphs attempt to @override the same field, a composition error occurs.

For more information, see Migrating entities and fields.

Arguments

Referencing external fields

@external

1
directive @external on FIELD_DEFINITION

Indicates that this subgraph usually can't resolve a particular object field, but it still needs to define that field for other purposes.

This directive is always used in combination with another directive that references object fields, such as @provides or @requires.

1
type Product @key(fields: "id") {
2
  id: ID!
3
  name: String! @external
4
  inStock: Boolean!
5
}
6

7
type Query {
8
  outOfStockProducts: [Product!]! @provides(fields: "name")
9
  discontinuedProducts: [Product!]!
10
}

This example subgraph usually can't resolve the Product.name field, but it can at the Query.outOfStockProducts query path (indicated by the @provides directive).

@provides

1
directive @provides(fields: FieldSet!) on FIELD_DEFINITION

Specifies a set of entity fields that a subgraph can resolve, but only at a particular schema path (at other paths, the subgraph can't resolve those fields).

If a subgraph can always resolve a particular entity field, do not apply this directive.

Using this directive is always an optional optimization. It can reduce the total number of subgraphs that your graph router needs to communicate with to resolve certain operations, which can improve performance.

1
type Product @key(fields: "id") {
2
  id: ID!
3
  name: String! @external
4
  inStock: Boolean!
5
}
6

7
type Query {
8
  outOfStockProducts: [Product!]! @provides(fields: "name")
9
  discontinuedProducts: [Product!]!
10
}

This example subgraph can resolve Product.name for products returned by Query.outOfStockProducts but not Query.discontinuedProducts.

For more information, see Using @provides.

Arguments

@requires

1
directive @requires(fields: FieldSet!) on FIELD_DEFINITION

Indicates that the resolver for a particular entity field depends on the values of other entity fields that are resolved by other subgraphs. This tells the graph router that it needs to fetch the values of those externally defined fields first, even if the original client query didn't request them.

1
type Product @key(fields: "id") {
2
  id: ID!
3
  size: Int @external
4
  weight: Int @external
5
  shippingEstimate: String @requires(fields: "size weight")
6
}

The example subgraph above resolves a Product object's shippingEstimate field, but it requires the product's size and weight to do so. Because these two fields are resolved by a different subgraph, they're marked as @external.

See also Contributing computed entity fields.

Arguments

Managing custom directives

@composeDirective

1
directive @composeDirective(name: String!) repeatable on SCHEMA

Indicates to composition that all uses of a particular custom directive in the subgraph schema should be preserved in the supergraph schema (by default, composition omits most directives from the supergraph schema).

1
extend schema
2
    @link(url: "https://specs.apollo.dev/link/v1.0")
3
    @link(url: "https://specs.apollo.dev/federation/v2.1", import: ["@composeDirective"])
4
    @link(url: "https://myspecs.dev/myDirective/v1.0", import: ["@myDirective", { name: "@anotherDirective", as: "@hello" }])
5
    @composeDirective(name: "@myDirective")
6
    @composeDirective(name: "@hello")

This directive has the following requirements:

• The directive to preserve must be defined and imported from a core specification via the @link directive.
• The specified directive name must match the name used for the directive in this subgraph.
  • If you use the as argument in your @link definition to modify the directive's name from its spec's default, provide the modified name, not the default name.
• If multiple subgraphs import and use the directive:
  • The name used for the directive must be identical in all of those subgraphs.
  • All of those subgraphs should use the same major version of the spec that defines the directive.

If any of these requirements is not met, composition fails.

Arguments