DgsRateLimit Prototype and Provide Extendibility to support Custom Annotation Logic

[sbilello]

Hi everyone!

I was evaluating few options on how to change the code execution flow and eventually abort the execution and/or add custom logic.
The Instrumentation is the recommended approach
Example:

@Component
@Slf4j
public class RateLimitInstrumentation extends SimpleInstrumentation {

    @Override
    public DataFetcher<?> instrumentDataFetcher(DataFetcher<?> dataFetcher, InstrumentationFieldFetchParameters parameters) {
        DgsContext dgsContext = parameters.getEnvironment().getContext();
        ServletWebRequest request = (ServletWebRequest) dgsContext.getRequestData().getWebRequest();
        Object object =  request.getAttribute(Constants.USER_CONFIG, ServletWebRequest.SCOPE_REQUEST);
        GraphQLFieldDefinition fieldDefinition = parameters.getEnvironment().getFieldDefinition();
        log.info("GraphQLFieldDefinition {}", fieldDefinition.getName());
        if (object != null) {
            UserConfig userConfig = (UserConfig) object;
            // TODO IMPLEMENT RATE LIMITING LOGIC 
            return c -> {throw new RateLimitException("over the threshold");};
        }
        else return super.instrumentDataFetcher(dataFetcher, parameters);
    }
}

This would have the exception caught over here https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/execution/ExecutionStrategy.java#L294.
It is a little bit down the road and I would love to stop early the execution without allocating Objects or Threads and allocating more resources.

So I wrote a small prototype: master...sbilello:dgs-custom-annotation-prototype

I left some comments because we might come up with an open design that would allow the developer to add custom annotations with relative custom logic.
Maybe extend the DgsSchemaProvider and/or all allow the developer to inject some custom beans implementing a new DgsInterface

Thanks for your review and the time spent answering my questions and comments @berngp @paulbakker @srinivasankavitha

P.S. I know that RateLimit is addressed at the gateway level but not all the GraphQL setup relies on Federation.

[berngp]

Hi @sbilello,
Thanks for the discussion. If your intention is to establish the rate limitation close to the execution fo the data fetcher, the method annotated with @DgsQuery or @DgsMutation, why not then use something like Resilience4j which is also supported by Spring Boot. In addition to the rate limitation that works out of the box you will also have circuit breakers and other features that will be hard, and inefficient, to implement directly in the DGS Framework.

Right now it will not be healthy for us to expose the DgsSchemaProvider since its an implementation detail that most likely will soon change. It will be great if instead we could leverage Spring's support of AOP to support this, in a similar manner as @Secured already works.

[sbilello]

Thanks, @berngp I need to have my customRateLimiter and it is not so simple as the one covered by RateLimit4j. In general, I wanted to have the capability to create a custom DGSAnnotation and relative logic without touching the DGSSchemaProvider
I might have some other custom operations to be performed :)
The AOP approach like the one for @Secured would be a good experiment to be done but I am not sure to have the time to study the @Secured implementation and extract the important part to make it work.
It would be a fun project for sure, I would evaluate with my team if we really want to move things forward in that direction or be pragmatic with Instrumentation and make it work :)
Thanks and have a great weekend!

[berngp]

I mentioned @Secured as an example but there are plenty out there.

ref.

1. Micrometer's @Timed Annotation and it's TimedAspect.
2. Spring's AOP Capabilities
3. Simple example here as well.

[sbilello]

I will look into it! Thanks