GraphQL API Rate Limiting

Point-Based Rate Limits

GraphQL was created to overcome shortcomings that REST APIs were not designed to address. Working with GraphQL has a number of advantages, one of which being the reduced number of HTTP calls required to obtain all of the data available through REST API.

However, calls to the GraphQL Admin API are limited based on estimated query costs, which means that the cost of queries over time should be considered rather than the amount of requests.

The points function in a very straightforward manner. A bucket of 1000 cost points is given to each app and store combination, with a leak rate of 50 cost points per second. This means that at any given time, the total cost of your queries cannot exceed 1,000 points, and that space in the app's bucket is created at a rate of 50 points per second. Plainly put, every second, you're given 50 points in a typical plan. Any mutation that requires you to edit, create, or delete data costs ten points. The cost of obtaining an object, on the other hand, is merely one point. Let's imagine you needed an order, but you also wanted each and every line item from that order. That isn't going to be a one-point penalty. If your order contains 10 line items, each of those line items will cost one point, and the order itself will cost one point, totaling 11 points.

The requested and actual query costs are combined to set the limit. Before the query can be executed, the app's bucket must have enough space to accommodate the desired cost. When the query is finished, the bucket is repaid the difference between the requested and actual query costs.

The cost of the request and the state of the throttle are included in the response. The following information is returned under the extensions key:

"extensions": {
    "cost": {
      "requestedQueryCost": 101,
      "actualQueryCost": 46,
      "throttleStatus": {
        "maximumAvailable": 1000,
        "currentlyAvailable": 954,
        "restoreRate": 50
      }
    }
  }
  

Taking these into consideration, our driver must calculate the appropriate quantity of data that can be retrieved each request to avoid throttling. The pagesize of a table is calculated automatically based on the number of fields and data in the table to conform to GraphQL API restrictions. Due to a low computed pagesize, performance for large tables in GraphQL may be lacking. An alternative is to increase the MaxPointsPerCall, which forces an increase in the pageisze, but we do not encourage this as it will most certainly result in throttling.

GraphQL Bulk API

Bulk operations, rather than single queries, are recommended to be used to query and get massive amounts of data.

Bulk operations are intended to handle massive amounts of data and do not have the same cost or rate constraints as single queries. You'll have to paginate your data sets if you don't utilize the bulk query. For REST, for example, a response can only include 250 elements. GraphQL is cost-based, but you're still limited to a specific number per request.

With a Bulk Operation API, this is not the case. Therefore, when using the GraphQL schema, we suggest setting UseBulkAPI to TRUE in the connection string to retrieve massive amounts of data without worrying about pagination or throttling.