Feature/custom layer operation support #41
Conversation
Add layerTransformation option to support custom layer operation for computing final complexity
|
That's an interesting idea. I think it would be nicer though to have this kind of functionality exposed in the estimator so that you can do this on a per-field basis (or a global estimator). You might have some parts in your graph where you need asymptotic complexity and others where you need the regular one. This would enable this feature via directive or other estimators: A change like that would pretty sure break backwards compatibility, but if we add this, I think this is the way we should go. This would keep it more modular and extensible, and if we for example pass the SelectionSet together with the full tree of child complexities to the estimator, this would also enable all kinds of other use cases and functionality. |
|
For "You might have some parts in your graph where you need asymptotic complexity and others where you need the regular one" use-case, I don't understand how this could be applied on per-field basis as it is computed "between" fields (on the same level). Enable this feature via directive as it is in example would be really strict and wouldn't allow much customization, because it allows only 2 options. And as I said, it is "between" fields, that means you cant assigned it to specific field. With solution like this using Goal of this PR is not to allow computing asymptotic complexity, but to allow computing complexity in the way developer wants (asymptotic in my case) |
I was thinking of a step that combines the complexity where the context is not lost and you have some more information about what values you are multiplying/adding besides the type. (What field, number of total selected fields). This would enable more usecases besides calculating asymptotic complexity. Maybe some kind of complexity reducer for a selection set that can be customized.
That was just an example, you could change the directive in any way you want, add enum types for multiple methods, write your own estimators, etc. Something like this: type ComplexityReducer = (params: {
type: GraphQLObjectType,
selectionSet: SelectionSetWithComplexity
}) => number;You would then have access to the number of selected fields, all complexity values of the entire selection set and child complexities, etc. |
|
With #46 being merged, the GraphQL node is now available inside of estimators. That way you have direct access to the selectionSet and can completely customize how complexities and child complexities are being calculated, also using asymptotic complexity. Only limitation: Since this is being calculated at the field level, this does not work for root query fields. For everything else you should be able to achieve what you're trying to do... |
Hi, thanks for nice library, it is really useful!
Although it probably wasn't original purpose of this library, we needed in our project to calculate and check asymptotic complexity of queries.
This can be done by multiplying instead of adding complexities on each level in query tree.
So field that has complexity of n can be set estimator like this:
-> So if childComplexity is also n, asymptotic complexity is n^2
Problem is that there is addition inside of
addComplexitiesfunction-> Fields on same level are added up.
So to solve this, I added
layerTransformation: LayerTransformationoptional option togetComplexityfunction to customize this behavior.To calculate asymptotic complexity you can just pass your own transformation function:
And to calculate asymptotic complexity on each query: