You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just an idea that I would benefit from in my situation. We have multiple availability zones, each with an instance (and a different URI) of our apollo gateway. I don't think this is possible in the current rover/supergraph builds, but it would be great to configure our supergraph with env vars to use for routing to subgraphs.
For example, in supergraph.yaml, provide a routing_url_var that can be set in place of routing_url.
Edit:
I just realized routing_url does not need to be an actual URL. So to get around, I was able to, e.g. provide a routing_url of var.SUBGRAPH_1_URL, and then in builldService() override, check for that convention and instead pull from process.env, e.g.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Just an idea that I would benefit from in my situation. We have multiple availability zones, each with an instance (and a different URI) of our apollo gateway. I don't think this is possible in the current rover/supergraph builds, but it would be great to configure our supergraph with env vars to use for routing to subgraphs.
For example, in
supergraph.yaml
, provide arouting_url_var
that can be set in place ofrouting_url
.Edit:
I just realized
routing_url
does not need to be an actual URL. So to get around, I was able to, e.g. provide arouting_url
ofvar.SUBGRAPH_1_URL
, and then inbuilldService()
override, check for that convention and instead pull from process.env, e.g.Beta Was this translation helpful? Give feedback.
All reactions