graphql-kotlin-federation library extends the functionality of the
graphql-kotlin-schema-generator and allows you to
easily generate federated GraphQL schemas directly from the code. Federated schema is generated by calling
toFederatedSchema function that accepts federated configuration as well as a list of regular queries, mutations and
subscriptions exposed by the schema.
All federated directives are provided as annotations that are used to decorate your classes,
properties and functions. Since federated types might not be accessible through the regular query execution path, they
are explicitly picked up by the schema generator based on their directives. Due to the above, we also need to provide
a way to instantiate the underlying federated objects by implementing corresponding
type resolution wiki for more details on how federated types are resolved. Final federated schema
is then generated by invoking the
In order to generate valid federated schemas, you will need to annotate both your base schema and the one extending it. Federated Gateway (e.g. Apollo) will then combine the individual graphs to form single federated graph.
If you are using custom
Query type then all of you federated GraphQL services have to use the same type. It is
not possible for federated services to have different definitions of
Base schema defines GraphQL types that will be extended by schemas exposed by other GraphQL services. In the example
below, we define base
Product type with
id is the primary key that uniquely
Product type object and is specified in
@key directive. Since it is a base schema that doesn't expose
any extended functionality our FederatedTypeRegistry does not include any federated resolvers.
Example above generates the following schema with additional federated types:
Extended federated GraphQL schemas provide additional functionality to the types already exposed by other GraphQL
services. In the example below,
Product type is extended to add new
reviews field to it. Primary key needed to
Product type (i.e.
id) has to match the
@key definition on the base type. Since primary keys are
defined on the base type and are only referenced from the extended type, all of the fields that are part of the field
set specified in
@key directive have to be marked as
@external. Finally, we also need to specify an "entry point"
for the federated type - we need to create a FederatedTypeResolver that will be used to instantiate the federated
Product type when processing federated queries.
Our extended schema will then be generated as:
Once we have both base and extended GraphQL services up and running, we will also need to configure Federated Gateway to combine them into a single schema. Using the examples above, our final federated schema will be generated as:
See our federation example for additional details.