Args and Outputs vs Nested Relations

[multipliedtwice]

Hello, thank you for the great library, really cool one. Could you please help me to figure out how to do 2 things:

1. Generated Args types
   How can I generate args types with "include" field relations?

2. Generated Outputs
   How can I generate relations together with "@field" decorator? Extending it doesn't really work because the key that I trying to add already exists. And changing the original key is unnecessary overhead. So I usually copy-paste the generated file and add @field manually to the custom copy.

What would be the best way to have relations for "GET"-kind of requests?

[MichalLytek]

1. Fetching relations is defined on the query level. The generated relations resolvers are taking care of getting the data you would normallya ask by "include".

2. I don't understand the question. Might be related to 1), so you want to declare the fields in model type and then manually include them in the Prisma Client call?

What would be the best way to have relations for "GET"-kind of requests?

This library is GraphQL oriented. If you want to mimic REST "fetch-all" approach, you need to find another project or stop using GraphQL 😄

[multipliedtwice]

1. Yep, on my project, I have custom resolvers, unfortunately.

2. Given the following example Model (yes, sorry, not Outputs) that is generated:

  @TypeGraphQL.Field(_type => String, {
    nullable: false
  })
  clientCompanyId!: string;

  clientCompany?: Company;

I want to query the company. How do I do that without changing the model?

[MichalLytek]

You write your own relations resolvers that uses @FieldResolver decorator. Or use the generated relation resolvers.

[multipliedtwice]

Can I simply copy-paste the generated model and then change it like this?

 @TypeGraphQL.Field(_type => String, {
    nullable: false
  })
  clientCompanyId!: string;

 @TypeGraphQL.Field(_type => Company, {
    nullable: false
  })
  clientCompany?: Company;

[MichalLytek]

The idea of graphql is to fetch when needed. That's why we use field resolvers instead of blindly calling include for every query.
You will forgot once about that in a mutation and bang you will get errors in your client.