Federation in StepZen

Creating a federated GraphQL API (supergraph) in StepZen is a two-step process. Let's start with a clean directory (e.g. federated):

1. Run stepzen import graphql to create two subgraphs

Run stepzen import graphql for each of the subgraphs.

For example, you could run

Copy
stepzen import graphql https://customers.acme.com/graphql --name=customers-proxy

Of course you would pick your GraphQL endpoint, which you might have built in StepZen, or might have built using some other technology.

Look at the code generated: StepZen now has a copy of the GraphQL backend, and it uses @graphql to connect to the backend. (This should be a familiar pattern — StepZen uses @rest to connect to REST backends, and @dbquery to connect to database backends.)

2. Link the subgraphs

Now these copies (proxies) can be linked together exactly how you would link a @rest backend with another @rest (or @dbquery) backend. That is, use @materializer to connect data in one proxy with a query in another. Your schema code looks like this:

Copy
extend type A-in-proxy-1 {
  newdata: [B-in-proxy-2]
    @materializer (query: "b-in-proxy-2")
}

The code in your federated folder is deployed to StepZen. Now you have a supergraph that when it receives a request, parses it to the right subgraphs and combines the results.

For information about @materializer, see Link Types: @materializer

Fancier stuff

stepzen import graphql --help gives you some other options.

• Use --prefix=foo to avoid name conflicts across your subgraphs.
• Use --header="..." to access a protected subgraph, both during import (build time) and runtime. StepZen takes that header information and moves it config.yaml so as not to leak authentication information into the API code.
• You can link two subgraphs together multiple times. The same type A-in-proxy-1 can be linked twice to B-in-proxy-2 (using different queries), or different types in proxy-1 can be linked to other types in proxy-2.
• You can delete queries or mutations from your supergraph that you do not want to expose to supergraph users. You do not have to delete types--we make sure that only th types that are accessible from the queries/mutations are visible to the supergraph users. In StepZen, you are basically manipulating text files, and this is in keeping with that philosophy.
• Managing changes in graphs. As your subgraph changes, your supergraphs might be affected. It is a good practice to keep the imported schemas and modifications separate. That way, a re-import does not destroy changes. If you re-import and then try to deploy, our static analysis will flag issues, and you can correct them as needed. This capability is an artifact of everything being just files.
• If you are a StepZen enterprise customer, you can develop your subgraphs locally using our docker image. For production, you have the option of running your graphs either in StepZen cloud, or in a StepZen managed service in your private cloud (VPC) or co-locations.