Colocating resolvers with the schema

[3x071c]

Is your feature request related to a problem? Please describe.
When I was looking to start a new GraphQL project, I almost went for this library paired with TypeORM, because colocation is an important concept to me - writing code that belongs together as close as possible instead of building abstractions in-between. Using (parts of) the same model to describe my GraphQL schema and the underlying database table, as shown directly on the front page of TypeGraphQL, is very powerful. One can immediately see the connection between the two, and it makes it easier to change something without surprises. However, it appears that this logic does not extend to resolvers, which are to be placed in a separate class. This is different from f.e. Nexus, where the resolver of a schema field is colocated in the same object as the field itself, and comes with all the previously mentioned drawbacks attached.

Describe the solution you'd like
Going from the code examples, it would seem very intuitive to be able to write Query/Mutation fields and field resolvers in the same model they belong to, in addition to being able to add unrelated resolvers in a separate file/class as it is being done right now.

Describe alternatives you've considered
I'm not aware of a documented way to do the above

[MichalLytek]

You can write your field resolvers inline as a methods of the model class.

However, placing queries as the model class methods would be a horrible designs.
Colocation is one thing, second is single responsibility principle.
Can you show me a REST framework that allows to write handlers (GET/POST) in model classes?

[3x071c]

I was thinking of being able to add decorators to a models fields to implement resolvers. Moving the resolvers to where they belong to does not violate single responsibility, in fact, it embraces it, as it allows completely encapsulating all logic that belongs to the same model in the same place (the same reasoning that justifies using decorators from f.e. TypeORM on a TypeGraphQL class - it's a sensible thing to do, instead of duplicating logic and creating dependence between files). I can't give you a REST framework as an example, but there's the aforementioned Nexus which competes in the same area as this library. I'd be excited to see your take on this, if you think this is as interesting as I do.

[MichalLytek]

I see that queries and mutation are located in one place, when the root query/mutation type is declared:
https://github.com/graphql-nexus/nexus/blob/main/examples/star-wars/src/graphql/query.ts

[3x071c]

I think that's not an ideal example. In a recent project, I've been using Nexus with Prisma in the resolvers like this. IMO it fits very well together, but I also like the idea of using classes with decorators. I'd be eager to try that with this library, if it's possible.

[MichalLytek]

TypeGraphQL design goals is to have resolver classes like REST controllers that support dependency injection via constructor.
I'm personally against the active record pattern, so I'm not suggesting any solutions of that kind.

Inline field resolvers aka model class methods are ecouraged only for simple tasks that doesn't involve any 3rd-party dependency.
The rest should be located in resolvers - you can have UserResolver class that contains boths queries and mutations related to User and the field resolvers for User type that do complex tasks like resolving DB relation between entities.