lrlna
commented
9 months ago degration of a service due to requesting an expensive root field multiple times in an attempt to scrape data from us
I am wondering if a protection against requesting too many expensive root fields would be better served with an upcoming cost limitation initiative we are working on. It would allow you to set a max cost per an operation, and let you define specific type costs on your subgraphs with @cost directive. The cost of an operation gets recursively summed based on some default weights or the weights you defined with the directive. Anything above that cost gets rejected. We are working on this initiative specifically to prevent routers from processing expensive operations.
Is your feature request related to a problem? Please describe. Currently the router supports a
max_aliasesoperation limit, this is global across the entire query and whilst it provides some mitigation against requesting the same resource multiple times it also limits the use of aliasing by the client to serve as a mechanism to rename fields.Describe the solution you'd like In addition to a global
max_aliasesamax_aliases_per_fieldoption would allow a limit on the number of times a specific field can be requested as opposed to a hard limit on the number of aliases within the query as a whole.There would be some questions about what the behaviour should be if a type appears multiple times in a response (would they be combined, would it just apply to arrays, etc.). The solution would also need to account for fragments.
Perhaps an initial first step would be just to alias limit on the root, which is generally where the most abuse can be done anyway (this is what we did with
@apollo/gateway.Describe alternatives you've considered Another option (or addition) could be to allow a limit on certain fields via configuration (or even better via schema directive). This would give the subgraph full control over invocations per request of a field.
Additional context We suffered degration of a service due to requesting an expensive root field multiple times in an attempt to scrape data from us. In mitigation we imposed a hard rule in
@apollo/gatewayto limit certain root fields to 'once per request'. We could reuse this in the router via a coprocessor or similar, but I believe it'd be worthwhile as a configuration, and to me the currentmax_aliasesconfiguration is well intended but not necessarialy solving the actual need for such a limitation.