Hi @Chris_Geelhoed,
Just to confirm, is your concern with the query cost? If so I’ve tested this on my own store, with a productVariants query that returns the expected amount of variants, and a collections query that returns the same amount of variants.
As we can see in the examples below, the actualQueryCost of the productVariants query I ran is more than the actualQueryCost of the collections query, when requesting only 20 product variants.
However the requestedQueryCost is higher due to the amount requested in all connections.
This is because the requestedQueryCost is calculated based on the total amount requested for all edges, even if that amount doesn’t exist on the store.
For example in the collections query, I requested 250, even though I know it will return 1 collection since I’m filtering by a single collection id.
If I reduce the first amount in the collections arguments, we can see that the requestedQueryCost is significantly lowered.
As for how this affects your rate limit, this is explained in further detail in the Shopify.dev documentation:
TLDR:
- rate limits use a combination of the requested cost, and the actual cost, when determining if your app’s rate point bucket has enough to complete the request, but then refunds the difference back to the bucket afterwards so it only uses the amount of the actual cost.
This means that you can use the workaround with the collections query, and reduce the cost of the query by reducing the amount requested in the first argument for each connector.
You should only be requesting the expected or lower amount of resources per connector, instead of just requesting the maximum limit of 250 per. You can then utilize pagination to request more if needed.
With that all said, as this is a duplicate issue from the thread that you linked, I will leave this thread marked as solved for now, and any further questions or comments on this issue can be addressed on the existing thread here: