Open Mithras opened 2 years ago
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)?
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
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.
Router supports overriding the Uplink API endpoints with the env var APOLLO_UPLINK_ENDPOINTS
, which is a list of URLs that provide the same API as Uplink. Unfortunately, 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) from GraphOS when I have a connection, but I want the option to provide fallback or cache the previously fetched versions, just incase my connection to GraphOS is blocked and I am deploying new instances of Router.
I have some ideas on ways we could accomplish this but it is still up to Apollo engineering to solve
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.
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
For those tracking we have a non-official solution solving this here: https://github.com/apollosolutions/uplink-relay
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
andAPOLLO_ROUTER_SUPERGRAPH_PATH
and useAPOLLO_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 withAPOLLO_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.