Router executed multiple requests to same subgraph to resolve entities

[alexus37]

Component(s)

router

Component version

0.130.0

wgc version

Just the router

controlplane version

Just the router

router version

0.130.0

What happened?

Description

While experimenting with the simple router example provided here, I noticed a missed opportunity for batching when resolving entities from a subgraph. Which is a blocker for us to adopt cosmo :/

Steps to Reproduce

After starting the router I executed the following request:

{
   employees {
    id
    products 
  }
  employee(id: 1) {
    id
    products
  }
}

This query touches two subgraphs and created the following Request Trace

Expected Result

I was surprised by the two calls to the "product" subgraph and would have expected them to be combined into a single call. These objects are even from the same source; however, I believe this approach should also work for different types by simply using the following syntax.

query ($representations: [_Any!]!) {
  _entities(representations: $representations) {
    ... on Employee {
      __typename
      products
    }
   ... on OtherObjectFromProductsSubgraph {
      __typename
      someField
    }
  }
}

Actual Result

Group all your calls together and send a single request to each subgraph.

[github-actions[bot]]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible. The roadmap is driven by our customers and we have to prioritize issues that are important to them. You can influence the priority by becoming a customer. Please contact us here.

[devsergiy]

Hi @alexus37

Not sure, how it is blocking you, as other router implementations are doing the same

It is not a bug, currently, it is designed like that

It is not a trivial thing to implement - you have nested calls for elements of a list of items (which will be batched) and then you have a nested call on another root query field which is an object

The tricky part here is to be able to multiplex representations from different places and then demultiplex them back, you should take into consideration that for each separate item in a list, each representation could already be null, and you still need to filter them In addition, you will need to merge queries, which could have the same types with different field selections and aliases

We have some thoughts on how to implement it, but it is not a priority right now

And we are always open for PRs :)

Thanks, Wundergraph Team