GraphQL Philosophy Question

[HunkyBill]

My scenario is one of wanting to know the availability of an SKU at each location. My target shop has 20 locations. They have a few thousand products. Each product has from 5 to 100 variants. GraphQL exposes the new InventoryItem and InventoryLevels to satisfy cravings for this snack. 

If I ask for a product, and all its variants, and all the locations and availability, this blows chunks with a cost > 4400.

OK... so now what? If I use cursors and loop through the inventory levels, the cost drops to around 600. A big chunk of the available 1000 if it used that. The reality is 11. So what if there are 20 locations? We would lose 11 * 22 = 242 actual units quickly for a product. We would also have to juggle the product cursor at the same time as the inventory levels cursor.

Alternatively, as suggested earlier by a Shopifier, perhaps we iterate the variants? A cursor on 10 is a cost of 445. Again, a big chunk of 1000 even though in actual use it kills only 5.

So the question I have here is managing cost vs network calls. It seems wrong to pretend making 10 API calls to get a variant just to stay in a skinny range of actual cost use is an advantage. All we've done is addressed payloads with a metric-ton of cursors and API calls, network latency issues, and gateway timeouts. 

So what is the advantage again? I am curious as to how this simple problem is best solved.

[SBD_]

Hey @HunkyBill,

I just ran a few tests. Consider starting with locations:

locations(first:10) {
  edges {
    node {
      id
      name
      inventoryLevels(first:10) {
        edges {
          node {
            id
            available
            item {
              sku
            }
          }
        }
      }
    }
  }
}

So the question I have here is managing cost vs network calls. It seems wrong to pretend making 10 API calls to get a variant just to stay in a skinny range of actual cost use is an advantage. All we've done is addressed payloads with a metric-ton of cursors and API calls, network latency issues, and gateway timeouts. 

If you're still hitting these issues, check out bulk operations.

[HunkyBill]

And if there are 11 locations, you missed one there. So now you have a third cursor in play. So you're making:

1 call to initialize

2 calls to get up to 20 locations

and 10 more calls to get up to 100 variants.

So one product is potentially 12 calls. To be efficient?

[SBD_]

Yeah it's not ideal. This type of query is well suited to bulk operations:

mutation {
  bulkOperationRunQuery(
   query: """
    {
      locations {
        edges {
          node {
            id
            name
            inventoryLevels {
              edges {
                node {
                  id
                  available
                  item {
                    sku
                  }
                }
              }
            }
          }
        }
      }
    }
    """
  ) {
    bulkOperation {
      id
      status
    }
    userErrors {
      field
      message
    }
  }
}

And then to check on the status:

query {
  currentBulkOperation {
    id
    status
    errorCode
    createdAt
    completedAt
    objectCount
    fileSize
    url
    partialDataUrl
  }
}