Performance Issues Graphql Products/Variants

GraphQL Admin API Troubleshooting
,
1

I am working on a new app and since the announcement and forced migration to GraphQL I wrote the graphqlQL query that I would need to retrieve products for the new app and variants with fragments and @include to be able to selectively add information when needed.

When I ran the query it took over 19seconds to return 660 products. I removed all the “extra” information like metafields and concentrated on only the information that I would have gotten back by simply hitting the products rest endpoint and I got the time down to around 11 seconds. The rest api took in comparison 1.7 seconds to return the same amount of records!

Here is my GraphQL query

  query getProducts(
    $first: Int!, 
    $after:String, 
    $query:String, 

  ) {
      products(first: $first, after:$after, query:$query) {
        pageInfo {
          hasNextPage
          endCursor
        }
        nodes {
          id
          title
          handle
          descriptionHtml
          description
          productType
          tags
          vendor
          publishedAt
          createdAt
          status
          hasOnlyDefaultVariant
          images(first:10){
            nodes{
              altText
              url
            }
          }
          options {
            name
            position
          }
          variants(first:100){
            pageInfo{
              hasNextPage
              endCursor
            }
            nodes{
              id
              displayName
              barcode
              taxable
              sku
              price
              compareAtPrice
              inventoryQuantity
              inventoryItem{
                requiresShipping
                id
                measurement{
                  weight{
                    unit
                    value
                  }
                }
              }
              selectedOptions{
                name
                value
              }
            }
          }
        }
      }
    }

{
    "first": 250,
    "query":"status:ACTIVE"
}

Please fix this before forcing us developers and app developers to migrate!

We are building a Public app and want it to be performant. I want to know that if we build it now using the REST api that we will not be prevented from getting the app through the review cycle, come on guys the performance difference is absolutely horrible, and please don’t suggest using bulkoperation where every connection is on its own line, thats a mess I really have no desire to even start thinking about.

Cheers,
Gary

2

Hey Gary,

Thanks for sharing this example - I’ve brought this to the attention of the team who are working on improving the performance of GraphQL mutations. As we ship improvements here, you can expect queries like this to speed up.

3

@Liam-Shopify

Thanks for answering. Just a question though, why was there such a push to deprecate the REST api when its obvious that the performance of the GraphQL API is in some instances up to 10x slower, by a factor of 10 more complex to actually get “most” standard tasks done (I’ve seen some improvements there with the productSet mutation, but its still buggy - drops images unexpectedly and does not report an error). It doesn’t make much sense to me.

We are being forced to use a slow, buggy API to build our new Public app which will probably take twice as long to build now as with the REST api and be 10x as slow. Not exactly a technological leap forward at this point. I do hope that we get some huge increases in performance and stability in the very near future.

BTW fragments that are conditionally included in a query should not push the actual query cost up if they are not actually included. Just having them within the submitted query increases actual costs. I was hoping to build some more complex queries where I can conditionally include connections but it looks like I will have to revert to actual server side snippet includes instead of using the built in graphql @include

Cheers,
Gary