server icon indicating copy to clipboard operation
server copied to clipboard

Implement Timeouts and Throttling Like GitHub GraphQL API

Open RehanSaeed opened this issue 7 years ago • 6 comments

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.

RehanSaeed avatar Aug 07 '18 08:08 RehanSaeed

any plans on implementing this?

ravividap avatar Jul 14 '21 13:07 ravividap

It would be really great to have this. We are awaiting a pull request; are you interested in contributing?

Shane32 avatar Jul 14 '21 22:07 Shane32

There is some likelihood that I'll do it, because it will be needed (although not the most important task) at my work.

sungam3r avatar Nov 18 '21 23:11 sungam3r

it will be needed (although not the most important task) at my work.

Ditto... just have not had the time to spend on it

Shane32 avatar Nov 19 '21 01:11 Shane32

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.

Shane32 avatar Nov 19 '21 03:11 Shane32

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

sungam3r avatar Jun 16 '22 06:06 sungam3r