GraphQL throttling

[flavio-b]

Overview/summary

It doesn't seem like the gem has built-in handling of throttling for GraphQL, as it does for REST.

With REST being somewhat deprecated, are there any plans to handle GraphQL throttling inside the gem, or do we have to inherit/extend from the client and implement a custom throttling solution around the query method?

This seems like a weird omission, because the REST throttling is taken care of, but I couldn't find anything for GraphQL.

[lizkenyon]

Hi there 👋

This is something the team has definitely discussed.

Could you tell us more about in what use cases you are hitting the GraphQL API rate limit?

[flavio-b]

We can hit the limit at any point, depending on what the merchant is doing. For example, if the merchant has a few staff members logged in the app and performing actions that call the GraphQL API, they can exhaust the points available.

Or, more commonly, we have a loop with pagination, to work through multiple records.

In both cases, a simple sleep, like the REST API does, might do the trick.

I created this wrapped client that we're testing.

[lizkenyon]

We can hit the limit at any point, depending on what the merchant is doing. For example, if the merchant has a few staff members logged in the app and performing actions that call the GraphQL API, they can exhaust the points available.

What sort of actions are you doing here to see this?

[flavio-b]

We haven't converted all our calls from REST to GraphQL, so I don't have any expensive queries to share, yet.

With REST, we pretty much only hit the limits during a loop that updates variant SKUs. It updates up to a few thousand variants or so. That's when throttling comes into play.

In this loop, we'll have to replace the REST call with GraphQL mutations, and we'll surely still hit some limits. We can't use a bulk mutation in this because we can only proceed to the next variant after confirming the previous has been saved successfully.

In another part of the app, we should have a GraphQL query that pulls 250 variants, their Product, plus InventoryItems, InventoryLevels and Metafields. We also have to pull multiple Orders, their LineItems, Fulfillments, Customer, Addresses, and Metafields.

These should be rather expensive, and we need to ensure that it's handled smoothly if the merchant (and staff) are hitting these queries too fast.

Right now, we don't really hit limits with REST in this part of the app because the basic Product and Order endpoints already bring almost all the associated data we need.

[lizkenyon]

Thank you for this context!

[flavio-b]

You're very welcome! So, basically, I don't know yet precisely what queries we'll have (aside from that loop), but I suspect they will use a decent amount of points. The app tends to handle a large number of objects, and their associations, per request. Also, it's one where a merchant/staff often trigger multiple of these requests within the minute or so.

And, once we get comfortable with GraphQL, we'll want to do more with it, pull new objects that we hadn't had access to before, and making more complex calls, so hence my concern with throttling handling.