CRUD Resolver Generation that separates Prisma client calls from Resolver actions

[jbeckton]

I was wondering how difficult it would be to alter the resolver code generation so that instead of making prisma client call inside the resolver but rather provide a generated service to the resolver via dependency injection that wraps the prisma client. This would allow us to extend the service / override certain method or provide a custom implementation of the service at runtime via di container.

From this...

@TypeGraphQL.Resolver((_of) => User)
export class FindManyUserResolver {
  @TypeGraphQL.Query((_returns) => [User], {
    nullable: false,
  })
  async findManyUser(@TypeGraphQL.Ctx() ctx: any, @TypeGraphQL.Info() info: GraphQLResolveInfo, @TypeGraphQL.Args() args: FindManyUserArgs): Promise<User[]> {
    const { _count } = transformInfoIntoPrismaArgs(info);
    return getPrismaFromContext(ctx).user.findMany({
      ...args,
      ...(_count && transformCountFieldIntoSelectRelationsCount(_count)),
    });
  }
}

To this...

@TypeGraphQL.Resolver((_of) => User)
export class FindManyUserResolver {
  constructor(private readonly userService: UserService) {}

  @TypeGraphQL.Query((_returns) => [User], {
    nullable: false,
  })
  async findManyUser(@TypeGraphQL.Ctx() ctx: any, @TypeGraphQL.Info() info: GraphQLResolveInfo, @TypeGraphQL.Args() args: FindManyUserArgs): Promise<User[]> {
    return this.userService.findManyUser(ctx, args, info);
  }
}

Essentially, we could provide a custom implementation for UserService at runtime if desired via the container config. Otherwise the generated service is a simple wrapper that is provided the prisma client via di.

I see a number of benefits to this. It allows the developer to provide custom code to access the prisma client at time of usage. One scenario I have is I would like to use CASL Prisma integration for row and field level auth but currently that would require me to write all my resolvers manually.

Another benefit might be that it allows us to overcome issues like what is being described here by allowing us to implement run time checks where needed.

And finally, there may be benefits to removing the prisma client from the context object and just injecting it into the generated service. Or making it optional, there may be use cases where the developer needs the prisma client in the context object so they can access it via middleware as needed.

Thanks.