Our Partner & Developer boards on the community are moving to a brand new home: the .dev community forums! While you can still access past discussions here, for all your future app and storefront building questions, head over to the new forums.

Re: graphql requestedQueryCost and actualQueryCost

Solved

graphql requestedQueryCost and actualQueryCost

GrantDB
Shopify Partner
80 3 14

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
                                }   
                            }
                        }
                    }
                }
            }
Accepted Solution (1)

KarlOffenberger
Shopify Partner
1873 184 903

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.

View solution in original post

Replies 2 (2)

KarlOffenberger
Shopify Partner
1873 184 903

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.

GrantDB
Shopify Partner
80 3 14

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