Conversations about creating, managing, and using metafields to store and retrieve custom data for apps and themes.
I am after some confirmation on my understanding and possible advice
I am using Shopfy graphql and I under stand the notion of leaky bucket and throttling.
When I conduct some calls (see below as an example) the difference between requestedQueryCost and actualQueryCost looks quite large, for example requestedQueryCost of 125 and an actualQueryCost of 6
My understanding is that when a bucket is checked, to see if there is space, it is the requestedQueryCost value that is used.
There seems to be a big gap between the two values meaning that a call can be rejected, even though there is plenty of space based on the actualQueryCost.
I know I can streamline the request, for example only ask for some metafields, rather than all of them, for example just requesting 2 metafields gives me requestedQueryCost of 25 and an actualQueryCost of 5, which is better.
My general feeling is that if I want a lot of information I can quickly hot the limit. For example to update lots of metadata fields I would need to get them, get their IDs and then update them.
Am I missing something?
Thanks
Grant
{ productByHandle(handle: "%s"){ id title handle metafields (first:100){ edges { node { description id key legacyResourceId namespace value valueType } } } resourcePublications (first:10) { edges { node { publishDate publication{ id name } } } } } }
Solved! Go to the solution
This is an accepted solution.
Nope, not missing anything. The discrepancies between requested and actual cost are unavoidable. So as you already touched upon, the best course of action is to optimise your queries. You can use request header X-GraphQL-Cost-Include-Fields set to true to get more granular insight over how cost is distributed over your query and fields.
Generally, I prefer using REST API when going deep in to a resource hierarchy (e.g. order response returns everything and your mother in law) even though it's wasteful - it's simply affordable. GraphQL for anything that can't be done in REST API or when not querying beyond 1 connection.
This is an accepted solution.
Nope, not missing anything. The discrepancies between requested and actual cost are unavoidable. So as you already touched upon, the best course of action is to optimise your queries. You can use request header X-GraphQL-Cost-Include-Fields set to true to get more granular insight over how cost is distributed over your query and fields.
Generally, I prefer using REST API when going deep in to a resource hierarchy (e.g. order response returns everything and your mother in law) even though it's wasteful - it's simply affordable. GraphQL for anything that can't be done in REST API or when not querying beyond 1 connection.
My general learning from this was to start by querying more than you need, prove it works. When you do this output the extra query cost information. Then change the query to just get the information you need and see how that affects the costs. Then decide on what you want to do