Accessing to resolver metadata in middleware

[erencay]

Providing metadata/resolver information into a middleware operation might have some benefits for extended use cases.

Example Use Case:
In this example I wanted to change level field to a fixed value if user is not an admin.

Decorator example;

function ValueUnlessAdmin<T>(val: any) {
    return function(inputCls: any, field: any) {
        Reflect.defineMetadata("valueUnlessAdmin", val, inputCls.constructor, field);
    };
}

InputType example;

@InputType()
class CreateUserInput {
    @Field()
    @ValueUnlessAdmin("member") // Creates metadata
    level: string;
}

Middleware example;

class SetValues implements MiddlewareInterface<Cntx> {
    async use({ context, args }: ResolverData<Cntx>, next: NextFn) {
        // At this point one might want to use metadata
        return next();
    }
}

export const schema = buildSchemaSync({
    resolvers: [UserResolver],
    globalMiddlewares: [SetValues],
});

Here's a suggested workaround by @19majkel94

> technically you can create a class decorator to mark an input class that it has special decorator like @ValueUnlessAdmin
> they both can use Reflect.defineMetadata to store some data attached
> and then in middleware you can browse the info object to search if the mutation use an input type with this custom decorator
> middlewares don't know if next is a middleware or a resolver so they have no access to compiled resolver params
> so you can't get array of params with instances of classes and make some checks
> and input type field have no middlewares or guards and input types are only data transfer object, they're not executed, no logic there

This workaround did the trick. That being said, it could be easier to realize such intentions and may be more if metadata/resolver information can be accessed in the middleware.

[MichalLytek]

Here is a quick snippet with my vision of the API:

const setValues: MiddlewareFn<Cntx> = ({ context, args, resolverMetadata }, next) => {
  // if resolverMetadata is defined, the next in chain is a resolver
  if (resolverMetadata) {
    // clone original args data object
    const customArgs = { ...args };
    for (const argMetadata of resolverMetadata.args) {
      // if arg is an input
      if (argMetadata.isInput) {
        // load custom metadata value from custom storage using InputType class
        const unlessAdminMetadatas = loadMetadataFromCustomStorage(argMetadata.classType);
        // do the logic - replace with the value when not admin
        for (const metadata of unlessAdminMetadatas) {
          if (!context.user.roles.include("admin")) {
            customArgs[argMetadata.argName][metadata.fieldName] = metadata.value;
          }
        }
      }
    }
    // call the next middleware (resolver) with replaced args object
    return next({ args: customArgs });
  }
  // if not, normally call next
  return next();
};

It's just an idea how to implement it exposing the resolverMetadata object, a draft of the metadata.

[MichalLytek]

I am revisiting this issue and I am thinking about a different way as injecting built metadata into middlewares is not so easy.

What if:

@ValueUnlessAdmin("member") // Creates metadata
level: string;

would use #124 to add some metadata to the GraphQLObject/InputType field?
This would solve:

At this point one might want to use metadata

Because this should be available in an info property of the middleware. You would have to navigate throught the resolve info tree, find all input types with fields that has provided metadata and do the conversion.

@erencay What do you think? Would it solve your use case? 🤔

[MichalLytek]

After a small research, it looks like #124 will allow to attach the custom data to the GraphQLObjectType and others, so it will be easily accessible in middlewares:

export const SampleMiddleware: MiddlewareFn = async ({ info }, next) => {
  const resolverMetadata = info.parentType.getFields()[info.fieldName];
  // here we can access `resolverMetadata.complexity` or other metadata
  return next();
};

I will add this recipe to the docs describing the metadata feature, maybe in the future there will be another argument of middleware function with injected parsed data like this.