Add support for fallback Supergraph

[Mithras]

Is your feature request related to a problem? Please describe. There is no simple way to provide a fallback Supergraph to use in case something is wrong with Apollo Studio.

Describe the solution you'd like We want to specify both APOLLO_GRAPH_REF and APOLLO_ROUTER_SUPERGRAPH_PATH and use APOLLO_ROUTER_SUPERGRAPH_PATH as a fallback in case something is wrong with Apollo Studio.

Describe alternatives you've considered If Router exited when failed loading Supergraph using APOLLO_GRAPH_REF, I could catch it and start it with APOLLO_ROUTER_SUPERGRAPH_PATH instead. Because Router just outputs "ERROR apollo_router::router: error downloading the schema from Uplink: UpLink" and doesn't exit (which is probably good), there is no simple way of restarting it with fallback Supergraph.

[Mithras]

Another idea is to add a link to a fallback Supergraph to APOLLO_UPLINK_ENDPOINTS but I'm not sure I understand how it works. Does it pull from the second/third/etc address only if previous has failed? E.g. if I have something like APOLLO_UPLINK_ENDPOINTS='https://aws.uplink.api.apollographql.com/, https://uplink.api.apollographql.com/, http://my/fallback/supergraph.graphql', will it do what I expect (pull fallback supergraph only if Apollo urls fail)?

[Geal]

the uplink schema download does round robin between each URL, like the gateway, so if some of them fail it will end up trying them all, and once it has downloaded a schema once, it keeps it until it manages to download a new one, so adding your URL to APOLLO_UPLINK_ENDPOINTS should be enough

[smyrick]

To add clarification to others who come across this issue, you can provide the schema to a Router instance at start up time with the --supergraph flag. Setting this however does disable the GraphOS connection to fetch supergraph updates (what we call the Uplink API) so you will not be able to use Managed Federation.

The APOLLO_UPLINK_ENDPOINTS is a list of URLs that provide the same API as Uplink. It is not simply an endpoint that links to a file download, so providing a custom url here would require you to mock out the entire Uplink endpoint which we don't have documentation for.

So the feature request here, which is still very valid, is that I want to be able to use GraphOS Managed Federation and pull my supergraph (and other assets like Persisted Queries) when I have a connection, but I want the option to provide fallback just incase my connection to GraphOS is blocked.

---

I have some ideas on ways we could accomplish this but it is still up to Apollo engineering to solve

Reuse the Redis cache that we use for PQs and Query Plans

We have an option to cache documents like the operations and query plans in-memory but we can fallback to reading them from a Redis instance if they are not found. In a similar fashion the supergraph could first default to fetching from the Uplink API but if that fails, reach out to the Redis cluster. This would also require that Router instance push schemas with their versions to Redis after a successful pull from Uplink.

Allow setting a supergraph file in the flags but still keep an open connection to GraphOS

Today if you specify the --supergraph flag this disables the Router from polling GraphOS to get schema updates. If there was some other flag to change this behaviour so at least maybe that file was treated as a fall back we could still spin up new instances.

Or to make it even more explicit, because allowing this does open up the potential of running different versions of the supergraph schema, we add a new start up flag --fallbackSupergraph which is the file to use if Uplink fails

[smyrick]

For those tracking we have a non-official solution solving this here: https://github.com/apollosolutions/uplink-relay