Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batching interface types #11

Open
trickleup opened this issue Mar 14, 2019 · 1 comment
Open

Batching interface types #11

trickleup opened this issue Mar 14, 2019 · 1 comment

Comments

@trickleup
Copy link

trickleup commented Mar 14, 2019

Hi, I'm seeing an issue when batching interface types. I have a query that returns an interface, that resolves to a few different types. Then, on each of those types, I query an interface field. In this case, it seems that the resolutions are batched by type. I wonder if this is intentional, if there's a known way to override it, or work around it?

For example, in the following query, the lookup query returns an array of MyInterface types, that all have a name property. However, the object with id abc123 is of TypeA and abc456 of TypeB (both implementing MyInterface).

# Write your query or mutation here
{
  lookup(
    ids: [
      "abc123"
      "abc456"
    ]
  ) {
    meta {
      name
    }
  }
}

In this case, the batch resolver creates two batches, and I would like it to create one. E.g. is it possible to group based on interface instead of concrete type?

@calebmer
Copy link
Owner

This library uses two heuristics for batching:

  1. All resolvers that are run before the next event-loop run are batched.
  2. All resolvers that are run with the same query AST node are batched.

I doubt it’s the second heuristic that’s broken here. Is there any reason why your two interfaces would resolve on different event-loop ticks? Can you make a minimal viable reproducing case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants