Automatic query complexity

[oprypkhantc]

Closes #610

This is based on Hot Chocolate's query complexity. The way this works is it sets a complexityFn on each field, which webonyx/graphql-php uses to determine each field's complexity.

I felt like including Cost information in the schema is important so clients can actually estimate a cost for a specific query before even thinking of writing it. Unfortunately, with the current state of GraphQL, there's no other way to add "meta" information to fields other than the description. This is why I'm adding cost information to the field "comments", although I'd much prefer something like a @cost directive. Sadly, that's not possible.

[oojacoboo]

This is awesome @oprypkhantc - thanks! I'll be testing an implementation as well.

[oojacoboo]

So, one thing I am noticing is that, without the ability to base the multiplier off the actual number of objects retrieved in a collection, you're forced to set your default limits in such a way that's already calculating the upper bounds of the overall complexity limit. This is mostly a concern if the client isn't always passing the limit (take) and it's defaulting (int $limit = 50). It does make implementation a bit more thoughtful, to achieve optimal complexity calculations. The benefit is that it encourages more thoughtful default limits and you get better test coverage as it's calculating against the assumed upper bounds.

Regardless, there isn't a way around this to still achieve static analysis - just an observation.

[oojacoboo]

@oprypkhantc I don't see anything around mutations. Will this work on mutations, input type fields?

[oprypkhantc]

@oojacoboo It's designed only to work on selections; input fields are not calculated towards query complexity. Is there a reason for it to work for input fields? In our case mutations are generally small, so too many input fields is definitely not a problem for us.

[oojacoboo]

The issue with not having cost complexity associated with mutations is that you're left with needing to resolve mutation abuse another way - especially considering that write operations are expensive. By having costs associated with mutations, you can mitigate this concern. And by adding cost complexity to fields of an input type, you have more control over the accuracy of the cost calculations for a mutation.