When resolving on a federated service, you can decide whether you resolve a field as a reference (which then gets resolved by another federated service) or whether you resolve it’s data directly.
The decision of whether to use a reference has several implications:
On the one hand, another trip (or several more) to a different federated service will be necessary but on the other hand, each service can get less specialized and the workload gets distributed.
If you have the possibility to fetch all the data, should you do that and at which point would you say it is too much? Are there any general strategies you follow here?
Hello! When deciding whether “Subgraph A” should be able to resolve certain entity fields from “Subgraph B” with the @provides directive, here are a few initial questions you can ask:
Does Subgraph A already connect to the data source(s) used to populate those fields? (if not, adding this connection might be unwise for your infrastructure)
Are both subgraphs maintained by the same team in your organization? (if not, future modifications to the fields can be more challenging)
Are both subgraphs implemented in the same language and framework? (if not, it can be more difficult to maintain identical behavior between the two resolvers)
Do your graph’s clients execute operations that might be entirely resolvable by Subgraph A if it provides these fields? (if so, it’s more likely that this optimization will provide meaningful improvements to responsiveness, although improvements are possible regardless)
If the answer to most or all of these questions is “yes”, I’d say you have a strong candidate for @provides.