From b6a920d0b37de6d19b9caab048e686ecc717d320 Mon Sep 17 00:00:00 2001 From: Maria Elisabeth Schreiber Date: Fri, 20 Sep 2024 09:08:35 -0600 Subject: [PATCH] Link fix --- docs/source/entities/migrate-fields.mdx | 2 +- .../federation-2/moving-to-federation-2.mdx | 12 ++++++------ .../federation-2/new-in-federation-2.mdx | 12 ++++++------ docs/source/federation-versions.mdx | 18 +++++++++--------- docs/source/hints.mdx | 2 +- docs/source/index.mdx | 2 +- docs/source/managed-federation/overview.mdx | 2 +- docs/source/subgraph-spec.mdx | 6 +++--- 8 files changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/source/entities/migrate-fields.mdx b/docs/source/entities/migrate-fields.mdx index 106533eb7..f4668010a 100644 --- a/docs/source/entities/migrate-fields.mdx +++ b/docs/source/entities/migrate-fields.mdx @@ -322,7 +322,7 @@ For most use cases, Apollo recommends using the [`@override` method above](#incr Using `@override` to migrate entity fields enables us to migrate fields incrementally with zero downtime. However, doing so requires three separate schema publishes. -If you're using [manual composition](./federated-types/composition#manually-with-the-rover-cli), each schema change requires redeploying your router. +If you're using [manual composition](./federated-schemas/composition#manually-with-the-rover-cli), each schema change requires redeploying your router. With careful coordination, you can perform the same migration with only a single router redeploy. 1. In the Billing subgraph, define the `Bill` entity, along with its corresponding resolvers. These new resolvers should behave identically to the Payment subgraph resolvers they're replacing. diff --git a/docs/source/federation-2/moving-to-federation-2.mdx b/docs/source/federation-2/moving-to-federation-2.mdx index e02e1efd5..4dcf057da 100644 --- a/docs/source/federation-2/moving-to-federation-2.mdx +++ b/docs/source/federation-2/moving-to-federation-2.mdx @@ -168,9 +168,9 @@ You can update your subgraphs one at a time. The steps below describe how to mod Federation 2 provides powerful new features that require making some changes to your subgraphs. These features include: -- Selectively sharing types and fields across subgraphs with [`@shareable`](../federated-types/federated-directives#shareable) -- Safely migrating fields from one subgraph to another with [`@override`](../federated-types/federated-directives#override) -- Hiding internal routing fields from graph consumers with [`@inaccessible`](../federated-types/federated-directives#inaccessible) +- Selectively sharing types and fields across subgraphs with [`@shareable`](../federated-schemas/federated-directives#shareable) +- Safely migrating fields from one subgraph to another with [`@override`](../federated-schemas/federated-directives#override) +- Hiding internal routing fields from graph consumers with [`@inaccessible`](../federated-schemas/federated-directives#inaccessible) The schema changes you make are not backward compatible with Federation 1, which means you won't be able to use Federation 1 composition anymore unless you revert those changes. @@ -203,7 +203,7 @@ This definition identifies a schema as a Federation 2 schema, and it `import`s a Depending on your schema, you might need to add other federated directives to the `import` array, such as `@external` or `@provides`. -[See all Federation-specific directives.](../federated-types/federated-directives/) +[See all Federation-specific directives.](../federated-schemas/federated-directives/) @@ -234,7 +234,7 @@ Some subgraph libraries are "code-first" (they dynamically generate their schema -Definitions for all Federation 2 directives are available in [this article](../federated-types/federated-directives/). We work with library maintainers to help automatically add these schema definitions in as many subgraph libraries as possible. +Definitions for all Federation 2 directives are available in [this article](../federated-schemas/federated-directives/). We work with library maintainers to help automatically add these schema definitions in as many subgraph libraries as possible. ### Mark all value types as `@shareable` @@ -288,7 +288,7 @@ You can also apply `@shareable` directly to a type definition (such as `Position -For more details, see [Value types](../federated-types/sharing-types/). +For more details, see [Value types](../federated-schemas/sharing-types/). ### Update entity definitions diff --git a/docs/source/federation-2/new-in-federation-2.mdx b/docs/source/federation-2/new-in-federation-2.mdx index 119535543..be90b3578 100644 --- a/docs/source/federation-2/new-in-federation-2.mdx +++ b/docs/source/federation-2/new-in-federation-2.mdx @@ -55,7 +55,7 @@ type Book { In Federation 2, this "identical definition" constraint is removed. Value types and their fields can be shared across subgraphs, even if certain details differ between definitions. -For details, see the sections below, along with [Value types](../federated-types/sharing-types/). +For details, see the sections below, along with [Value types](../federated-schemas/sharing-types/). ### Objects @@ -82,7 +82,7 @@ type Book @shareable { -The two `Book` type definitions above differ in terms of the fields they include and the nullability of those fields. Notice also the new [`@shareable`](../federated-types/sharing-types/#using-shareable) directive, which is required to indicate that a field can be resolved by multiple subgraphs. +The two `Book` type definitions above differ in terms of the fields they include and the nullability of those fields. Notice also the new [`@shareable`](../federated-schemas/sharing-types/#using-shareable) directive, which is required to indicate that a field can be resolved by multiple subgraphs. @@ -95,13 +95,13 @@ This flexibility is especially helpful when an organization has multiple standal #### Valid shared field differences between subgraphs * The return type of a shared field can vary in nullability (`String` / `String!`). -* Types can omit fields that are included in other subgraphs, as long as every field in your supergraph is always resolvable. (For details, see [Rules of composition](../federated-types/composition/#rules-of-composition).) +* Types can omit fields that are included in other subgraphs, as long as every field in your supergraph is always resolvable. (For details, see [Rules of composition](../federated-schemas/composition/#rules-of-composition).) -For details on how these field differences are handled, see [Differing shared fields](../federated-types/sharing-types/#differing-shared-fields). +For details on how these field differences are handled, see [Differing shared fields](../federated-schemas/sharing-types/#differing-shared-fields). ### Enums, unions, and interfaces -In Federation 2, `enum`, `union`, and `interface` definitions can differ between subgraphs. For details, see [Merging types from multiple subgraphs](../federated-types/composition/#merging-types-from-multiple-subgraphs). +In Federation 2, `enum`, `union`, and `interface` definitions can differ between subgraphs. For details, see [Merging types from multiple subgraphs](../federated-schemas/composition/#merging-types-from-multiple-subgraphs). ## Entities @@ -222,7 +222,7 @@ For more information, see [Referencing an entity without contributing fields](.. ### Migrating fields -Federation 2 introduces the [`@override` directive](../federated-types/federated-directives/#override), which helps you safely migrate entity and root-level fields between subgraphs with managed federation: +Federation 2 introduces the [`@override` directive](../federated-schemas/federated-directives/#override), which helps you safely migrate entity and root-level fields between subgraphs with managed federation: diff --git a/docs/source/federation-versions.mdx b/docs/source/federation-versions.mdx index b1cebbb1f..d2143ec0b 100644 --- a/docs/source/federation-versions.mdx +++ b/docs/source/federation-versions.mdx @@ -4,7 +4,7 @@ subtitle: Understand changes between Apollo Federation versions description: Understand changes between Apollo Federation major and minor versions. --- -This article describes notable changes and additions introduced in each minor version release of Apollo Federation. Most of these changes involve additions or modifications to [federation-specific directives](./federated-types/federated-directives/). +This article describes notable changes and additions introduced in each minor version release of Apollo Federation. Most of these changes involve additions or modifications to [federation-specific directives](./federated-schemas/federated-directives/). For a comprehensive changelog for Apollo Federation and its associated libraries, see [GitHub](https://github.com/apollographql/federation/blob/main/CHANGELOG.md). @@ -71,7 +71,7 @@ Minimum router version -Introduced. [Learn more](./federated-types/federated-directives/#cost). +Introduced. [Learn more](./federated-schemas/federated-directives/#cost). ```graphql directive @cost(weight: Int!) on ARGUMENT_DEFINITION | ENUM | FIELD_DEFINITION | INPUT_FIELD_DEFINITION | OBJECT | SCALAR @@ -88,7 +88,7 @@ directive @cost(weight: Int!) on ARGUMENT_DEFINITION | ENUM | FIELD_DEFINITION | -Introduced. [Learn more](./federated-types/federated-directives/#listsize). +Introduced. [Learn more](./federated-schemas/federated-directives/#listsize). ```graphql directive @listSize(assumedSize: Int, slicingArguments: [String!], sizedFields: [String!], requireOneSlicingArgument: Boolean = true) on FIELD_DEFINITION @@ -153,7 +153,7 @@ Minimum router version -Introduced. [Learn more](./federated-types/federated-directives/#context). +Introduced. [Learn more](./federated-schemas/federated-directives/#context). ```graphql directive @context(name: String!) on OBJECT | INTERFACE | UNION; @@ -170,7 +170,7 @@ directive @context(name: String!) on OBJECT | INTERFACE | UNION; -Introduced. [Learn more](./federated-types/federated-directives/#fromcontext). +Introduced. [Learn more](./federated-schemas/federated-directives/#fromcontext). ```graphql scalar ContextFieldValue; @@ -237,7 +237,7 @@ Minimum router version -Added progressive `@override`. [Learn more.](./federated-types/federated-directives/#progressive-override) +Added progressive `@override`. [Learn more.](./federated-schemas/federated-directives/#progressive-override) ```graphql directive @override(from: String!, label: String) on FIELD_DEFINITION @@ -728,7 +728,7 @@ Minimum router version -Introduced. [Learn more.](./federated-types/federated-directives#composedirective) +Introduced. [Learn more.](./federated-schemas/federated-directives#composedirective) ```graphql directive @composeDirective(name: String!) repeatable on SCHEMA @@ -811,7 +811,7 @@ extend schema The `import` list of this definition must include each federation-specific directive that the subgraph schema uses. In the example above, the schema uses `@key` and `@shareable`. -For details on these directives as defined in Federation 2, see [Federation-specific GraphQL directives](./federated-types/federated-directives/). +For details on these directives as defined in Federation 2, see [Federation-specific GraphQL directives](./federated-schemas/federated-directives/). @@ -978,7 +978,7 @@ Value types diff --git a/docs/source/hints.mdx b/docs/source/hints.mdx index c55371ea6..9034cee1a 100644 --- a/docs/source/hints.mdx +++ b/docs/source/hints.mdx @@ -4,7 +4,7 @@ subtitle: Reference for composition hints description: Learn about hints flagged during Apollo Federation schema composition using GraphOS Studio or the Rover CLI. --- -When you successfully [compose](./federated-types/composition) the schemas provided by your [subgraphs](./building-supergraphs/subgraphs-overview/) into a supergraph schema, the composition process can flag potential improvements or hints. Hints are violations of the [GraphOS schema linter's](/graphos/delivery/schema-linter) [composition rules](/graphos/delivery/linter-rules#composition-rules). You can review them on the [Checks](/graphos/delivery/schema-checks) page in GraphOS Studio or via the [Rover CLI](/rover/). +When you successfully [compose](./federated-schemas/composition) the schemas provided by your [subgraphs](./building-supergraphs/subgraphs-overview/) into a supergraph schema, the composition process can flag potential improvements or hints. Hints are violations of the [GraphOS schema linter's](/graphos/delivery/schema-linter) [composition rules](/graphos/delivery/linter-rules#composition-rules). You can review them on the [Checks](/graphos/delivery/schema-checks) page in GraphOS Studio or via the [Rover CLI](/rover/). diff --git a/docs/source/index.mdx b/docs/source/index.mdx index 5e3337a69..4d66cb665 100644 --- a/docs/source/index.mdx +++ b/docs/source/index.mdx @@ -162,7 +162,7 @@ Depending on your goals, you have several options for learning more about federa Once you're ready to apply federation to your own APIs, these docs sections can help you get started: - [Quickstart](./quickstart) to get you up and running with a federated graph -- Conceptual overview of [Federated Schemas](./federated-types/overview) +- Conceptual overview of [Federated Schemas](./federated-schemas) - Reference materials for: - [Performance considerations](./performance/caching) - [Debugging and metrics](./errors) diff --git a/docs/source/managed-federation/overview.mdx b/docs/source/managed-federation/overview.mdx index 96fabad1f..1d4a4df96 100644 --- a/docs/source/managed-federation/overview.mdx +++ b/docs/source/managed-federation/overview.mdx @@ -10,7 +10,7 @@ import ManagedFederationDiagram from '../../shared/diagrams/managed-federation.m With managed federation, you maintain subgraphs and delegate GraphOS to manage CI/CD tasks including the validation, composition, and update of your supergraph: -* Your subgraphs publish their schemas to GraphOS, which stores them in its schema registry. GraphOS then [validates](./federated-schema-checks) and [composes](../federated-types/composition/) them into a supergraph schema. +* Your subgraphs publish their schemas to GraphOS, which stores them in its schema registry. GraphOS then [validates](./federated-schema-checks) and [composes](../federated-schemas/composition/) them into a supergraph schema. * Your routers can poll GraphOS—specifically, its [Apollo Uplink](./uplink) endpoint—to get the latest validated supergraph schema and other configurations. diff --git a/docs/source/subgraph-spec.mdx b/docs/source/subgraph-spec.mdx index 42f59b2a5..7eb9d49e3 100644 --- a/docs/source/subgraph-spec.mdx +++ b/docs/source/subgraph-spec.mdx @@ -105,7 +105,7 @@ Apollo strongly recommends against dynamic composition in the graph router. Dyna The "enhanced" introspection query above differs from [the GraphQL spec's built-in introspection query](https://spec.graphql.org/October2021/#sec-Schema-Introspection) in the following ways: - The returned schema representation is a string instead of a `__Schema` object. -- The returned schema string includes all uses of [federation-specific directives](./federated-types/federated-directives/), such as `@key`. +- The returned schema string includes all uses of [federation-specific directives](./federated-schemas/federated-directives/), such as `@key`. - The built-in introspection query's response does not include the uses of any directives. - The graph router requires these federation-specific directives to perform composition successfully. - If a subgraph server "disables introspection", the enhanced introspection query is still available. @@ -412,7 +412,7 @@ Your subgraph library does not need to use this reference resolver pattern. It j This section describes type and field definitions that a valid subgraph service must automatically add to its schema. These definitions are all listed above in [Subgraph schema additions](#subgraph-schema-additions). -For descriptions of added directives, see [Federation-specific GraphQL directives](./federated-types/federated-directives/). +For descriptions of added directives, see [Federation-specific GraphQL directives](./federated-schemas/federated-directives/). ### `Query` fields @@ -488,4 +488,4 @@ This string-serialized scalar represents an authorization policy. ### Directives -See [Federation-specific GraphQL directives](./federated-types/federated-directives/). +See [Federation-specific GraphQL directives](./federated-schemas/federated-directives/).
* To define a value type with shared fields across multiple subgraphs, those shared fields must be marked as `@shareable` in every subgraph that defines them. -* Value type fields can differ across subgraphs (in certain ways). For details, see [Differing shared fields](./federated-types/sharing-types#differing-shared-fields). +* Value type fields can differ across subgraphs (in certain ways). For details, see [Differing shared fields](./federated-schemas/sharing-types#differing-shared-fields).