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.

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

@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.

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.