Graphql on hand inventory query complexity

If I look for on hand inventory for a product, I can use a query like this, and the complexity is only 1.

  product(sku: "x"){
    data {

If I add the available field, it increases complexity to 31, making it much slower to get current available inventory for a group of products. Is there some reason for this complexity increase with available inventory?

Hi @joe, welcome!
That is a great question! The reason that the complexity of the available number is so much higher than the on-hand number is the amount of calculation and data points that are accessed in that calculation. For instance, the on-hand is pulling one value. The available has to touch on several values and calculate results based on the computation of values for a result. (to check if it’s virtual or if it is a kit, the kit component on-hand, the allocation, etc. )

Hi @joe,

I ran into this, too. I understand that it’s a calculated field and more computationally intense, but an extra 30 to the complexity per SKU seems really high in my opinion. (But I’m not a GraphQL server programmer, so what do I know?)

It’s not a pretty solution, but I wind up using the API for what I can, but then I’ll go to the Products page and manually export a CSV of everything just to get the available field and merge them with a script. It’s annoying because it’s manual, but only takes seconds instead of the hours it would take to get the same data via the API.

1 Like

Thanks for the explanation.

In my case I only have api access but it is disappointing when an api is more limiting than a report available to the end user.

It never occurred to me that one might have access only to the API. Yeah, that’s rough. :frowning:

This topic was automatically closed after 14 days. New replies are no longer allowed.