Skip to main content

Federation

Similar to schema stitching, Federating aims to expose a single gateway for multiple subgraphs. However, differing from schema stitching the relationship between subgraphs (or the way that two sources can be combined) is done at the subgraph level and not at the gateway.

Subgraphs are written with the knowledge of other subgraphs. For instance, there can be separate schemas for a Clubhouse and a Ride, however, in architectural decision making we are aware of both already being present and can therefore for add relevant types to each subgraph.

An example can be found here.

Federating graphql is similar to the relationship between sql queries where identifiers are used to resolve other tables, or in this case, schemas.

Overview

Pros

  • Don't have to manage the Gateway schema, once set up it remains untouched until we wish to add a new subgraph
  • More scaleable, as a reference is defined locally to the schema rather then globally as is done in schema stitching

Cons

  • Requires access to sub schemas, this is currently not possible with Contentful.