Using ./router without a supergraph schema... or how to generate a supergraph schema

hi everyone, we currently have a federation gateway implemented just using @apollo/gateway and we specify the subgraphs with something like this in the options:

subgraphs: [{ name: service.name, url: service.url, }, {..}, ...],

im now looking at using the ./router command instead, but im hitting a wall, mainly around how i specify the subgraphs. it seems like i need to pass in a supergraph schema in order to start the router, instead of specifying the name/urls of each subgraph. i have a couple of questions:

  1. its unclear in the documentation how to generate this supergraph schema. how do i do this?
  2. id much rather start the ./router command with just a list of the subgraphs and urls, similar to how its done in the @apollo/gateway package. is this possible with ./router ?

Hey @John_Kor ! Great questions.

  1. its unclear in the documentation how to generate this supergraph schema. how do i do this?

You can use rover supergraph compose, passing in a supergraph.yaml file that lists all your subgraph schemas and URLs.

supergraph.yaml:

federation_version: =2.10.0
subgraphs:
  products:
    routing_url: http://localhost:4000
    schema:
      file: ./products.graphql # Schema provided via file
  reviews:
    schema:
      subgraph_url: http://localhost:4001 # Schema provided via introspection, routing_url can be omitted
  users:
    # routing_url: <Optional, pulled from GraphOS registry by default>
    schema:  # Schema downloaded from GraphOS registry, does not poll for updates
      graphref: mygraph@current
      subgraph: actors

If you’re using GraphOS and publishing your subgraph schemas to Studio, then you can also directly use your graph credentials (APOLLO_KEY and APOLLO_GRAPH_REF) with the ./router command and it will take care of fetching the supergraph schema for you so you don’t have to use rover supergraph compose. Here’s the relevant docs page.

The command would look like this:

APOLLO_KEY="..." APOLLO_GRAPH_REF="..." ./router
  1. id much rather start the ./router command with just a list of the subgraphs and urls, similar to how its done in the @apollo/gateway package. is this possible with ./router ?

For local development, I recommend using rover dev, which spins up a local graph for you. Here’s the relevant docs page.

The command would look like this:

rover dev --supergraph-config supergraph.yaml

Hope that helps, let me know if you have any follow-up questions!

thanks so much for the quick response @Michelle_Mabuyo !

regarding point #1, understood!

regarding point #2, it sounds like theres a local development solution using rover dev. however, what about in production? what i like about the current implementation we have with @apollo/gateway is that we can just specify urls at start time as well as a polling interval so that the gateway is always up to date (ie. we can make changes to subgraphs in isolation without needing to restart our gateway)

with the current implementation of ./router in production (to the best of my knowledge), it seems as though whenever we make a change to a subgraph we will also need to regenerate a supergraph.schema while also restarting the gateway. am i understanding this correctly or is there better way to handle this? we do not use graphOS at the moment

Hey @John_Kor. I’m not sure you want the advice, so feel free to ignore it. Also, we do use graphOS, so I could be wrong about some of this.

First, both serviceList and its replacement, IntrospectAndCompose are recommended against use in production, due to their instability. If, for example, one service just happens to have downtime during a scale up, scale down, or restart event in your router, your entire API could go down.

As far as “new supergraph.schema while also restarting the gateway”, there is a --hot-reload flag, documented here that will watch the the supergraph file passed during startup. If you enable that flag, all you would have to do is replace that file, and it would update your schema.

Hey @dncrews thanks for the response! This is super helpful to know, as I didn’t know this before :slightly_smiling_face: I’ll work towards revising our setup asap so it uses a static super graph schema going forward. I don’t think I ever noticed this caveat in the docs for setting up Apollo/gateway initially so this is super helpful

We are looking for a solution that ideally does not require a subscription fee to graphos. Is there anything “free” available that would host an updated super graph schema? I personally find the Apollo docs and services available a bit hard to follow so any advice here would be appreciated. Cheers!

As for a solution, it depends on what you mean by “free” and what your needs are, but there are options.

The Guild released a collection of open source solutions that form a platform called Hive, which has a self-hosted option. I’ve never looked too deeply, so I don’t know the full compatibility or feature set compared either to their own paid solution or Apollo, and from the docs it looks like there’s a lot of infrastructure that might be needed.

If I were paying the bill from my own pocket, on a budget looking for a “much much more free, please” option, I’d probably just push the subgraph schemas to S3 during the deployment process. Then I’d build a lambda that is triggered from a file drop, which takes all of the schemas, composes a supergraph, and updates the file hosted alongside the router. There’s no frills here, but if your team is small enough that you don’t need the controls and change management of a platform, and all you need is a stable registry, there’s not much that is less expensive or more stable than a file in S3.

1 Like

@John_Kor, have you checked out the Apollo Free tier? With the free tier, you can publish your subgraph schemas to GraphOS and it composes the supergraph schema for you. Your router can then connect to the most up-to-date schema without needing to hot-reload.

And if there’s anything specific you’d like to share about what you’re having trouble with finding in the docs, please let me know! I work on the Education team at Apollo and definitely open to feedback for improving our content :slight_smile: