Skip to main content

Resource limitations

Important

This part of the GraphQL API is currently in Early Availability status. For more information, see GraphQL API policy.

Defining and enforcing API usage limits is an important component of maintaining a high-performance and reliable service. GraphQL presents unique challenges to services that aim to apply usage limits. A common approach used with REST is to set a max number of requests that are allowed to be made over a defined period of time (per hour, per day, and so on). GraphQL on the other hand allows queries for multiple resources to be made with a single call, resulting in a server load equivalent to hundreds of REST requests. So a different approach is required.

The AppDirect GraphQL API enforces usage limitations by calculating the expected cost of a query and enforcing the cost in two ways: request limits and rate limits. See the following topics for more information on how queries are calculated and enforced.

note

Resource limitations may change as AppDirect learns more about how developers use the AppDirect GraphQL API.

Cost calculation

To calculate the cost of a GraphQL query, AppDirect counts the number of requests required to fulfill a query and the number of nodes returned.

Calculated cost = number of requests + total number of nodes returned

Here is a simple example to help illustrate this calculation:

query {
product(id: "1234") {
name
type
}
}

The above query results in a cost of 1 point because the API only needs to make one request to retrieve product 1234.

Here is a slightly more complex query:

query {
product(first: 250) {
name
type
}
}

The query above results in a cost of 251 points because the API needs to make 1 request to retrieve a list of products and returns 250 products.

Query limit

Request limits define the number of points that are allowed by a single GraphQL request made by a client application. The current limit is 1000 points.

Rate limits

Rate limits define the maximum number of points that are allowed by a client application per minute, using a leaky bucket algorithm. Usage of a leaky bucket algorithm allows client applications to make an unlimited number of requests over a large time horizon but protects against excessively large bursts over a short one.

The current bucket size is 1000, with a leak rate of 100 points per second. This means that at any given time the cost of queries cannot exceed 1000 points and room is created in the bucket at a rate of 100 points per second.

Was this page helpful?