server
server copied to clipboard
Implement Timeouts and Throttling Like GitHub GraphQL API
Moved from https://github.com/graphql-dotnet/graphql-dotnet/issues/764.
Summary
GitHub implements timeouts and time based throttling as described here and here.
Motivation
We already have maximum depth and complexity settings we can use but timeouts and throttling are other common methods of securing GraphQL from abuse, used by GitHub and others.
any plans on implementing this?
It would be really great to have this. We are awaiting a pull request; are you interested in contributing?
There is some likelihood that I'll do it, because it will be needed (although not the most important task) at my work.
it will be needed (although not the most important task) at my work.
Ditto... just have not had the time to spend on it
I would like to expand a little on GitHub's calculations, so that nodes can have a different cost. In practice, nodes that relate to a database row might have a much higher cost than fields from that row. Also, nodes that contain non-collection lists can have a cost associated in anticipation of the number of rows being returned. And like GitHub, collection nodes can be calculated from the 'before' or 'after' argument, probably multiplied by a cost factor.
It would be really nice to prep the complexity analyzer to allow for all these calculations (part of GraphQL.NET), and allow for determining if it meets the throttling threshold based partly on prior executions (part of the server library). And this should work in conjunction with document caching, so an analysis does not need to be performed on cached queries.
We may even determine that we should design some type of new validation rule framework that allows for easy access to a node's arguments. As it is now, it is quite difficult for a validation rule to inspect field arguments, as can be seen in the InputFieldsAndArgumentsOfCorrectLength validation rule. (For instance, that sample completely ignores input value processing within the respective scalar graph type.) Then perhaps complexity analyzers in v5 will be entirely written as validation rules rather than having their own framework.
Just some ideas to think about.
Then perhaps complexity analyzers in v5 will be entirely written as validation rules rather than having their own framework.
Current status: https://github.com/graphql-dotnet/graphql-dotnet/pull/3172 https://github.com/graphql-dotnet/graphql-dotnet/pull/3179 https://github.com/graphql-dotnet/graphql-dotnet/issues/3177 https://github.com/graphql-dotnet/graphql-dotnet/issues/3175