Docs
Launch GraphOS Studio
You're viewing documentation for a previous version of this software. Switch to the latest stable version.

Subgraphs


This article describes how to create a subgraph for a federated using .

Defining a subgraph

To be part of a , a must conform to the Apollo Federation specification, which exposes the 's capabilities to the gateway, as well as to tools like Apollo Studio.

Converting an existing into a single is a convenient first step in building a federated . To start, here's a non-federated setup:

index.js
const { ApolloServer, gql } = require('apollo-server');
const typeDefs = gql`
type Query {
me: User
}
type User {
id: ID!
username: String
}
`;
const resolvers = {
Query: {
me() {
return { id: "1", username: "@ava" }
}
}
};
const server = new ApolloServer({
typeDefs,
resolvers,
});
server.listen(4001).then(({ url }) => {
console.log(`🚀 Server ready at ${url}`);
});

This should look familiar if you've set up Apollo Server before. If it doesn't, we recommend you familiarize yourself with the basics before jumping into federation.

Now, let's convert this to a . The first step is to install the @apollo/subgraph package in our project:

npm install @apollo/subgraph

Defining an entity

As part of our federated architecture, we want other to be able to extend the User type this defines. To enable this, we add the @key to the User type's definition to designate it as an entity:

index.js
const { ApolloServer, gql } = require('apollo-server');
const { buildSubgraphSchema } = require('@apollo/subgraph');
const typeDefs = gql`
type Query {
me: User
}
type User @key(fields: "id") {
id: ID!
username: String
}
`;

The @key tells other which (s) of the User type to use to uniquely identify a particular instance. In this case, should use the single id.

Next, we add a reference resolver for the User type. A reference tells the gateway how to fetch an by its @key :

index.js
const resolvers = {
Query: {
me() {
return { id: "1", username: "@ava" }
}
},
User: {
__resolveReference(user, { fetchUserById }){
return fetchUserById(user.id)
}
}
};

(This example requires defining the fetchUserById function to obtain the appropriate User from our backing data store.)

Generating a subgraph schema

Finally, we use the buildSubgraphSchema function from the @apollo/subgraph package to augment our schema definition with federation support. We provide the result of this function to the ApolloServer constructor:

index.js
const server = new ApolloServer({
schema: buildSubgraphSchema({ typeDefs, resolvers })
});
server.listen(4001).then(({ url }) => {
console.log(`🚀 Server ready at ${url}`);
});

The server is now ready to act as a in a federated graph!

Combined example

Here are the snippets above combined (again, note that for this sample to be complete, you must define the fetchUserById function for your ):

index.js
const { ApolloServer, gql } = require('apollo-server');
const { buildSubgraphSchema } = require('@apollo/subgraph');
const typeDefs = gql`
type Query {
me: User
}
type User @key(fields: "id") {
id: ID!
username: String
}
`;
const resolvers = {
Query: {
me() {
return { id: "1", username: "@ava" }
}
},
User: {
__resolveReference(user, { fetchUserById }){
return fetchUserById(user.id)
}
}
}
const server = new ApolloServer({
schema: buildSubgraphSchema({ typeDefs, resolvers })
});
server.listen(4001).then(({ url }) => {
console.log(`🚀 Server ready at ${url}`);
});

Securing your subgraphs

Because of the power and flexibility of the Query._entities and Query._service fields, your should not be directly accessible by clients. Instead, only your gateway should have access to your . Clients then communicate with the gateway:

Graph router
Users
subgraph
Products
subgraph
Reviews
subgraph
Web app
iOS app

Make sure to implement any necessary firewall rules, access control lists, or other measures to ensure that individual can be accessed only via the gateway.

Subgraph-specific symbols

When you generate your subgraph schema, some federation-specific definitions are automatically added to it. In addition to definitions like @key, the most useful of these definitions for debugging are two of the Query type: _service and _entities:

type Query {
# ...your field definitions...
# Added automatically
_service: _Service!
_entities(representations: [_Any!]!): [_Entity]!
}

Query._service

This returns a _Service object with one of its own: sdl. You can it like so:

query GetSubgraphSchema {
_service {
sdl
}
}

The sdl returns your 's schema as an string. This field has a couple of important differences from a standard introspection query that a tool like uses:

  • Unlike , the sdl is not disabled by default in production environments (this is safe if you properly secure your subgraph).
  • Unlike , the sdl 's returned string includes federation-specific like @key.

Whenever your gateway needs to fetch a 's schema (this occurs only if your gateway uses IntrospectAndCompose), it uses this instead of an so it can obtain federation-specific details.

Query._entities

Learn about entities if you haven't yet.

This takes a list of entity representations and returns a list of corresponding entities.

Whenever one erences another 's , it uses an entity representation to do so. An representation is an object that includes only the 's __typename and the in the 's @key.

_entities(representations: [_Any!]!): [_Entity]!
  • The _Any type is a special that enables you to provide representations of any valid shape.
  • The _Entity type is a generated union type that includes every defined in your 's schema.

You can this like so, providing a value for the $representations as shown:

Query
query ($representations: [_Any!]!) {
_entities(representations: $representations) {
... on User {
id
username
}
}
}
Variable
{
"representations": [
{
"__typename": "User",
"id": "5"
}
]
}

Using in tests and debugging

If you're writing integration tests for your , you can test the return value of the _entities for various representations that your other use.

If you're developing your in your local environment, you can mock the return value of the _entities for your other so you don't have to connect those subgraphs to their respective data stores.

Custom directives in subgraphs

The method for defining custom differs slightly for a federated , and it also depends on the version of you're using.

⚠️ Important considerations

Before you use in a federated , make sure to consider the following:

  • Custom are not included in your 's composed . The process strips all . Only a given subgraph is aware of its own directives.
  • Because are specific to individual , it's valid for different subgraphs to define the same with different logic. does not detect or warn about such inconsistencies.
  • If multiple can resolve a particular , each subgraph should almost always apply the exact same set of custom (with the exact same accompanying logic) to that field. Otherwise, the behavior of that field might vary depending on which resolves it.

Directives in Apollo Server 3.x

3 does not provide built-in support for custom , but you can install certain @graphql-tools libraries to enable support. To get started with these libraries in , first read Creating schema directives.

As the linked article describes, in 3 you define a transformer function for each of your 's custom .

To apply transformer functions to your executable , you first generate the with buildSubgraphSchema as usual:

let subgraphSchema = buildSubgraphSchema({typeDefs, resolvers});

But instead of passing the result directly to the ApolloServer constructor, you first apply all of your transformer functions to it:

// Transformer function for an @upper directive
subgraphSchema = upperDirectiveTransformer(subgraphSchema, 'upper');

After applying all transformer functions, you provide your final to the ApolloServer constructor as usual:

const server = new ApolloServer({
schema: subgraphSchema
// ...other options...
});

Directives in Apollo Server 2.x

Without Apollo Federation, you provide your definitions to the constructor of ApolloServer in the schemaDirectives , like so:

With Apollo Federation, you instead call SchemaDirectiveVisitor.visitSchemaDirectives, passing in your schema and your , before you provide your schema to the constructor of ApolloServer:

const { ApolloServer, gql, SchemaDirectiveVisitor } = require('apollo-server');
const { buildSubgraphSchema } = require ('@apollo/subgraph')
// typeDefs and resolvers defined here
class DeprecatedDirective extends SchemaDirectiveVisitor {
public visitFieldDefinition(field: GraphQLField<any, any>) {
field.isDeprecated = true;
field.deprecationReason = this.args.reason;
}
}
const directives = {
deprecated: DeprecatedDirective
};
let schema = buildSubgraphSchema({ typeDefs, resolvers });
SchemaDirectiveVisitor.visitSchemaDirectives(schema, directives);
const server = new ApolloServer({
schema: schema
});

Also make sure to read about the gateway's support for custom directives.

Previous
Part 3 - Working with subgraphs
Next
The gateway
Edit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy

Company