Feature Request: Complexity estimator receives all args to be used as multiplier factor
ale7canna opened this issue · 4 comments
Hi!
To have a more precise and reliable complexity estimation, I was wondering about the following feature.
I see your project already supports the multiplier
feature. But from what I can see in your code, it's only possible to operate on arguments directly applied to the query node itself.
For our use case, it would be nice to have all the query arguments, all the way down to the estimated node. I'll try to explain to you why.
This is how we structured our queries when list and pagination are involved:
query userPosts {
user {
id
name
surname
blogPosts (pagination: {page:1, pageSize:3}) {
count
items {
id
post {
id
title
body
}
}
}
}
}
user
, blogPosts
, and post
are resolved by different endpoints/services.
Our main goal is to apply the multiplier factor to the resolution of post
. So the complexity of post
's resolution should be multiplied by the pageSize
parameter/argument. So far, that's not possible because the estimator does not receive all the query arguments, but only the node's ones.
It would be awesome to have all the arguments available and use them for complexity computation 👍
What do you think about this? I would be happy to contribute, too!
Not sure I understand the problem here correctly. You can assign the post
field a complexity and then use the multiplier on the blogPosts
field. Since post
is a child field of that, the multiplier is also applied to the child complexity, so you should get a pretty accurate estimate.
Otherwise, there's always the option to create a custom estimator on the blogPosts
field. The entire selection set is passed to the estimator. So you could implement pretty much any fancy logic you want. But using the child complexity and the multiplier looks like it might be the right approach for you usecase?
Hi @ivome and thanks for your answer.
You're right, I could use the complexity with the multiplier
arg at the blogPosts
level.
But in the case of the following query, the result will be misleading (since I'm not resolving the post
entity):
query userPosts {
user {
id
name
surname
blogPosts (pagination: {page:1, pageSize:3}) {
count
items {
id
}
}
}
Let me know what you think. However, thanks for your hint. I'll give a look at the custom estimator approach :)
If you don't include post
in the query, it won't be part of the child complexity. But items
would, so you could add the complexity there.
I'm closing this here for now as I don't think there is a need to change the library. This can be achieved with custom estimators and / or child complexity. Feel free to reopen with a concrete example if you see a need to add functionality.