Gqlgen: Implement complexity as a plugin

[mia0x75]

schema:

type Query {
    posts(count: Int = 10): [Post!]!
}

type Post {
    title: String!
    text: String!
    related(count: Int = 10): [Post!]!
}

when depth limit equals to 2:
valid query:

{
    posts(count: 100) { # depth = 1
        related(count: 100) { # depth = 2
        }
    }
}

invalid query:

{
    posts(count: 100) { # depth = 1
        related(count: 100) { # depth = 2
            related(count: 100) { # depth = 3
                related(count: 100) { # depth = 4
                    title
                }
            }
        }
    }
}

[mathewbyrne]

We have a query complexity feature that you can use to limit which queries are allowed to run. The handler.ComplexityLimit option allows you to control the limit.

[mia0x75]

I knew it, from my understanding, query complexity limits the return count of fields, but I don't care about the count, I just want to limit the depth, is that possible?

this one is valid:

posts -> related posts
      -> likes
      -> ...

this is invalid:

posts -> related posts -> related posts
                       -> likes
                       -> ...
      -> likes
      -> ...

when the depth limit equals to 2.

[qhenkart]

I strongly second this. It is the field depth that causes issues, not the field length. The documentation really shows the field depth in the examples as well. Currently the feature conflates data/schema modeling with query complexity. Actually this is a major piece for us that will force us to fork before we can use this library for production. I'd be happy to work on an OS contribution with some direction

[Kay-Zee]

Also interested in a depth based complexity limit as an option.

[vektah]

We want to pull query complexity out into a plugin which will at the very least means you can provide a custom implementation without forking.

I don't think it's as simple as what you describe though in practice. While

posts -> related posts -> related posts

Is too deep

Viewer -> user > name

Isn't

Complexity is meant to capture what is hard and make it multiplicitivly harder the deeper you go, in this case related posts should have a high complexity, so you can't go very deep, but user, viewer and name have low complexity so going deep is ok

[qhenkart]

@vektah that would be great! But in terms of your examples, if I were designing my own plugin, I would design it so all depth is considered equal and model around that. Which means both of your examples would be equally complex (and I would set the complexity count and model my subresolvers appropriately),

I think the issue that folks are touching on is that

posts -> related posts -> related posts

should have the same complexity as

Viewer -> user > name

and

Viewer -> user > name

should have the same complexity as

Viewer -> user > name , email , id

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qhenkart]

keeping this alive because it's an important feature despite its marking as low priority

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.