The initial subgraph already resolves a@shareablefield and returns it.
A second subgraph requires the same@shareablefield using @requires.
Instead of passing the existing value which was already retrieved, the router calls a different subgraph again to resolve the field.
When trying different solutions we also tried @provides where for a specific query, the Subgraph would provide a certain field which is otherwise owner by another Subgraph. While doing Entity resolution and another Subgraph requiring (@requires) that same field, instead of the router passing it on, it goes back to the Subgraph which owns the field.
In our case this creates problem because the value of the field can be different based on query context.
Has anyone experienced something similar to this and maybe tried a different approach?
Happy to provide more details.
I think the problem is that with @provides, it will quite literally resolve that field in the context of where the @provides is labeled. When you use @requires on that provided field, the query planner likely intends to use an entity query, which makes it traverse down a different path and therefore, sends a new request since the value is “nested” inside the higher level provided query.
Could it be optimized so it can recognize that the provided field is on an entity and can be reused? Probably, I’ll defer to the Apollo team on whether that should already be occurring, and if not, if it could.
What could fix it? If you are able to write an entity resolve for your entity on the subgraph that uses @provides such that you could resolve the entity based on its key, and then use @shareable instead of using the @provides directive, then I think the query planner will be able to reuse the retrieved field instead of go to the source. However, this may introduce more usage of that subgraph to resolve that field than you originally intended because the router could choose to go to that subgraph for resolving that field for other queries.
One other thing that I think you said outside of this thread was that the field itself can’t always be resolved by just the key because it needs the context of something else. I haven’t used it yet, but @context seems promising. It looks like you can use it across multiple subgraphs. See the Referencing fields across subgraphs section docs.