Support for mutation namespaces

[dan-cooke]

Is your feature request related to a problem? Please describe.
When developing with type-graphql you often notice your class files are growing absolutely enormous.

Describe the solution you'd like
One cool paradigm is the use of mutation namepsaces https://graphql-rules.com/rules/mutation-namespaces.

This alows consumers of your graphql schema to go way beyond REST and instantly see what mutations are available for a given entity.

Describe alternatives you've considered
I have tried to implement something like this within the framework. As follows:

@Resolver(() => Portfolio)
class PortfolioResolver {
 @Mutation(() => PortfolioMutationNamespace)
  async mutatePortfolio(
    @Arg(`_id`, () => ObjectIdScalar)
    _id: ObjectId,
    @Ctx() { identity }: GraphQLContext,
  ) {
    const portfolio = await PortfolioModel.findById(_id);

    if (portfolio?.owner.sub !== identity.sub) {
      throw new AuthenticationError(
        `You do not have permission to update this portfolio`,
      );
    }

	// Return the namespace
    return new PortfolioMutationNamespace(_id);
  }
}

@Resolver(() => Portfolio)
export class PortfolioMutationNamespace {
  private _id: ObjectId;

  constructor(portfolioId: ObjectId) {
    this._id = portfolioId;
  }

  @Mutation(() => UpdatePortfolioPayload)
  async setName(@Arg(`name`) name: string) {}
}

But I get Cannot read property 'getObjectType' of undefined and error when building my schema.

It seems that a @Mutation() needs to return an @ObjectType and it currently does not support returning another @Resolver type.

If the library supported this use case, it would be awesome!

[MichalLytek]

Closing as rejected multiple times in #1045 #781 #712 #312 #64 etc. 🔒

[dan-cooke]

Apologies @MichalLytek .

I just saw a few of the previous issues after I posted this. I did not think about serial vs parallel mutations in this instance. OBviously this will need to be supported in the graphql spec first

Thanks for your awesome library!