Query Complexity

[michaelstaib]

This feature shall provide more security options to the execution engine.

Sometimes, the depth of a query is not enough to truly know how large or expensive a GraphQL query will be. In a lot of cases, certain fields in our schema are known to be more complex to compute than others.
Query complexity allows you to define how complex these fields are, and to restrict queries with a maximum complexity. The idea is to define how complex each field is by using a simple number. A common default is to give each field a complexity of 1. Take this query for example:

query {
  author(id: "abc") { # complexity: 1
    posts {           # complexity: 1
      title           # complexity: 1
    }
  }
}

A simple addition gives us a total of 3 for the complexity of this query. If we were to set a max complexity of 2 on our schema, this query would fail.
What if the posts field is actually much more complex than the author` field? We can set a different complexity to the field. We can even set a different complexity depending on arguments! Let’s take a look at a similar query, where posts has a variable complexity depending on its arguments:

query {
  author(id: "abc") {    # complexity: 1
    posts(first: 5) {    # complexity: 5
      title              # complexity: 1
    }
  }
}

Query Complexity Pros

• Covers more cases than a simple query depth.
• Reject queries before executing them by statically analyzing the complexity.

Query Complexity Cons

• Hard to implement perfectly.
• If complexity is estimated by developers, how do we keep it up to date? How do we find the costs in the first place?
• Mutations are hard to estimate. What if they have a side effect that is hard to measure like queuing a background job?

https://www.howtographql.com/advanced/4-security/

[michaelstaib]

see also https://sangria-graphql.org/learn/#protection-against-malicious-queries

[michaelstaib]

This is a nice way to annotate complexity and specify the multipliers.

type Participant {
  # The complexity of getting one thread in a thread connection is 3, and multiply that by the amount of threads fetched
  threadConnection(first: PaginationAmount, after: String): ThreadConnection @cost(complexity: 3, multipliers: ["first"])
}

type Thread {
  author: Author @cost(complexity: 1)
  participants(first: PaginationAmount,...): [Participant] @cost(complexity: 2, multipliers: ["first"])
}

[michaelstaib]

Multipliers should be limited to built-in scalar types since the variables are not coerced at the time we validate. Since we have the schema we could coerce simple variables on the go.

[michaelstaib]

https://developer.github.com/v4/guides/resource-limitations/

[michaelstaib]

Look also at what the GitHub guys did.

[michaelstaib]

I will add support for variables to the validation rules.

[michaelstaib]

#456

[michaelstaib]

https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b

[michaelstaib]

Fields can be annotated with the @cost directive. The @costdirective contains two arguments, complexity which is the general complexity for this field and multipliers which are a list of arguments of the field that multiply the complexity by default.

The algorithm for field complexity can be replaced by a custom algorithm. The complexity algorithm can be defined for all fields or one can opt to add a specific algorithm for specific fields.

builder.AddOperationComplexityRule((field, complexity, multipliers) => 
{
  // ... custom code
});

or

builder.AddOperationComplexityRule(
    "TypeName",
    "FieldName",
    (field, complexity, multipliers) => 
    {
      // ... custom code
    });

[michaelstaib]

This issue was closed by accident.

[michaelstaib]

This one is now implemented