slicknode/graphql-query-complexity

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!

ivome commented

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 :)

ivome commented

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.

ivome commented

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.