Graphql: Entity decorators?

[caseyduquettesc]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

While the resolvers, queries, and mutations can be written in Typescript, the entities must be put in .gql files. For those of us also using TypeORM, it requires two definitions of the models.

Expected behavior

Some of the features of TypeGraphQL look like they would fit in perfectly in this ecosystem. Much like the current autodiscovery of resolvers, I was hoping to have GQL entities autodiscovered using decorators.

import { ObjectType, Field, Float } from 'type-graphql';
import { Entity, Column, OneToMany } from 'typeorm';

@Entity()
@ObjectType()
class Recipe {
  @Field()
  @Column()
  title: string;

  @Field({ nullable: true })
  @Column({ nullable: true})
  description?: string;

  @Field(type => [Rate])
  @OneToMany(() => Rate, rate => rate.recipe)
  ratings: Rate[];

  @Field(type => Float, { nullable: true })
  @Column({ nullable: true })
  get averageRating() {
    const sum = this.ratings.reduce((a, b) => a + b, 0);
    return sum / this.ratings.length;
  }
}

Maybe nestjs/graphql already works with type-graphql and I just haven't figured out how to do it. Was hoping for some compatibility or comparable features offered.

Minimal reproduction of the problem with instructions

Above snippet good enough?

What is the motivation / use case for changing the behavior?

Single source of truth for data models

Environment

Nest version: 5.3.10


For Tooling issues:
- Node version: 8.11
- Platform:  Mac

Others:

@nestjs/graphql: 5.4.0
@nestjs/typeorm: 5.2.2

[caseyduquettesc]

I guess I can get this working with no duplication of code using the code sample from issue https://github.com/nestjs/graphql/issues/49, but I feel like I'm missing out on nice to haves by not using the nestjs/graphql package. Also had to delete the graphql package from type-graphql because it conflicted the peer dependency of this library.

Also found this issue (https://github.com/19majkel94/type-graphql/issues/135) in the type-graphql repo, which is essentially what this issue was getting at. So feel free to close this or keep open for tracking it here

[kamilmysliwiec]

We'll provide an integration soon

[esistgut]

Is there any update about this? Having multiple type definitions (typeorm entities, .graphql SDL files and auto generated typescript definitions from SDL) doesn't feel right.

[kamilmysliwiec]

@esistgut it depends. Generating everything is not always a good decision. Also, I'm a big opponent of treating entities as DTOs classes. Anyway, the integration will be probably provided very soon, however, Nest users will still have a choice to pick whatever they prefer (generate graphql/generate typings/don't generate anything)

[esistgut]

I'm sorry, I couldn't think of the benefits of the current approach. I'm used to the django/graphene design (graphql types are not defined directly on the entities but on other objects which are configured with the linked entity https://docs.graphene-python.org/projects/django/en/latest/tutorial-plain/#hello-graphql-schema-and-object-types) so I was just trying to do things in a similar way.

[nmabhinandan]

@kamilmysliwiec

I'm a big opponent of treating entities as DTOs classes

Then what is your recommended way of doing things?

As of now, we're generating classes for each types and and manually marking them as typeorm entities. Since nestjs has official integration with typeorm, it wouldn't be too _out the scope_ if it this package and optionally generated typeorm entities IMO.

[kamilmysliwiec]

Then what is your recommended way of doing things?

Absolutely creating separated classes, even if some simple properties would have to be duplicated then.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.