GraphQL Complexity Limit
Context
GraphQL queries offer flexibility and customization to users, allowing them to define their own queries.
However, this advantage can also be a potential drawback, as users may execute queries that consume significant resources.
Limit Enforcement
To prevent overloading the GraphQL engine with excessively complex and resource-intensive queries, a complexity limit is enforced on the public GraphQL API.
This limit defines the maximum allowed complexity for a query.
Result when Limit is Reached
If a query exceeds the complexity limit, the API response will contain an error message indicating that the maximum allowed operation complexity has been exceeded.
The response may include additional information such as the actual complexity of the query and the allowed complexity.
{
"errors": [
{
"message": "The maximum allowed operation complexity was exceeded.",
"extensions": {
"complexity": 900000,
"allowedComplexity": 100000,
"code": "HC0047"
}
}
]
}
Maximum Complexity Limit
100000
In order to ensure optimal performance and prevent potential overload situations, a maximum complexity limit of 100,000 has been chosen for Sage Active Public API V2 queries.
This value takes into account the maximum allowed pagination values for first
and last
, which are set to a maximum of 500.
By setting the complexity limit to 100,000, it allows for a wide range of queries to be executed within the GraphQL API while still maintaining a manageable level of complexity.
This recommended value helps strike a balance between query flexibility and system resource utilization.
- If it happens that the complexity limit is reached and you encounter any issues, it is advisable to contact Sage to explain the context and discuss the possibility of increasing the current limit.
- By providing the necessary information about your specific use case and requirements, Sage can assess the situation and determine if an adjustment to the complexity limit is warranted.
- This proactive approach ensures that the GraphQL API operates smoothly and efficiently, meeting your application’s needs while maintaining optimal performance.
Default Complexity Calculation
The default calculation algorithm in HotChocolate considers the complexity of the query fields and their child fields, as well as any specified multiplicative factors.
If no valid multiplier is found, a default multiplier is applied to adjust the final cost.
Example of GraphQL query complexity calculation:
query {
paymentTerms (
first: 2
after: null
){
edges {
node {
id
name
lines {
day
order
}
}
}
}
}
Let’s break down the complexity calculation for this query:
- Each field has a default complexity value assigned to it.
- The complexity of a field is determined by its type and any custom complexity rules defined.
- The complexity of the query is calculated by summing up the complexities of all the fields and their child fields.
- Additionally, any specified multiplicative factors are taken into account.
In this example, the final cost of the query is determined as follows:
- The
paymentTerms
field has a complexity of 5 (default resolver complexity). - The
edges
field has a complexity of 6 (node). - The
node
field has a complexity of 6 (id, name, lines). - The
lines
field has a complexity of 7 (id, day, condition, type, value, payDays, paymentMeanId).
Field Name | Field Type | Complexity | Child Complexity | Sum |
---|---|---|---|---|
day | Int! | 1 | 0 | 1 |
edges | [PaymentTermsEdge!] | 1 | 6 (node) | 7 |
id | UUID | 1 | 0 | 1 |
lines | [PaymentTermLineGLDto!] | 1 | 2 (day + order) | 3 |
name | String | 1 | 0 | 1 |
node | PaymentTermGLDto! | 1 | 5 (id + name + lines) | 6 |
order | Int! | 1 | 0 | 1 |
paymentTerms | PaymentTermsConnection | 5 | 7 (edges) | 12 |
Considering the first
attribute in the GraphQL query is set to 2, the multiplier is 2.
The final cost of the query is calculated by multiplying the total complexity by the multiplier:
Final cost = paymentTerms
x multiplier
= 12 x 2 = 24
But beware:
The final cost can rise very quickly.
With this example of a request, it immediately reaches 12000, in particular because of the multiplier effect of the pagination value defined here at its maximum of 500.
query {
paymentTerms(first: 500, after: null) {
edges {
node {
id
name
lines {
id
day
condition
type
value
payDays
paymentMeanId
}
}
}
totalCount
pageInfo {
hasNextPage
}
}
}
HotChocolate Official Documentation
For more detailed information on operation complexity and its configuration, refer to the official HotChocolate documentation: HotChocolate Operation Complexity