We have set of subgraphs which are owned by different teams in separate code bases, separate CICD pipelines. Now while updating @apollo\gateway
to 0.50.0
and we are running into the issue for composition failure when one of the subgraphs fails. This was not the case with version 0.10.0
of @apollo\gateway
). We are using IntrospectAndCompose
to create apollo gateway. Is there any way to handle it? Any guidance for such distributes subgraphs scenario as serviceList
is deprecated with latest version of @apollo/gateway
?
Hey @riteshbhoi. IntrospectAndCompose
is a drop-in replacement for serviceList
, there should be little to no difference in behavior.
If composition fails because a subgraph fails (I’m not totally sure what you mean by “a subgraph fails”), I’d expect you to see failures whether you’re using IntrospectAndCompose
or serviceList
. Are you seeing something different as a result of upgrading?
Ultimately, the real solution to this problem is managed federation. With managed federation, Apollo knows about your supergraph regardless of the immediate status of your subgraphs. This allows your gateway to start successfully.
thanks @trevor.scheer for your response. What I meant by “a subgraph fails” is, let’s say a subgraph is not available and that subgraph API fails with 500 result code, gateway is not impacted. Gateway can still compose other available subgraphs with serviceList
. But that is not the case with IntrospectAndCompose
If the gateway is unable to get the schema for a particular subgraph, it cannot expect to create a valid supergraph. In some edge cases, it’s possible for it to compose without errors, but this isn’t a behavior you want to rely on. This holds true for all forms of composition (including IntrospectAndCompose
and serviceList
).
A simple example of why this is bad is: suppose your users
service is down, and it defines an entity User
. How should the gateway create a meaningful supergraph when its subgraphs extend User ...
? This doesn’t work.
You’re running a very old version of gateway, so it wouldn’t surprise me if the behavior you’re expecting is something that we fixed at some point. I would not recommend depending on this behavior going forward.
I completely agree with you. I wanted to confirm that this change was done on purpose. Thanks for clarifying the same.
Happy to help. Good question!