I ran into a typescript error on user module working on 'Added queries to resolvers' part.

providers: [UserService, UserResolver, CommentService] <- this line.

Error message is "Type instantiation is excessively deep and possibly infinite"

Dear @kelvin-mai ,

first of all: This tutorial is awesome 🎉 Really nice work!

I have a question regarding the use of the Partial<Entity> in your update(...) methods, like in the linked code snippet for the controller:

and the corresponding service:

As far as i understood, the Partial<IdeaDTO> only tells, that it must be an IdeaDTO, but it must not be "fully filled" (e.g., not all values must be present). Wouldn't it be better to "remove" the Partial part and directly use the IdeaDTO in this case and use the @IsOptional() decorator from the class-validator package?

My thought process is as follows:
Consider the example, where you have different DTOs based on the operation you are calling (e.g., a CreateUserDTO and UpdateUserDTO). For the CreateUserDTO you may provide different attributes than for the UpdateUserDTO (like, the user is not allowed to change his username after registration).

This way you could enforce the user, that he must send certain attributes with the request (e.g., they must be present!). For example, in order to change your user-profile you must send the current password to prove your identity!

Further, it would be much cleaner, if you use Swagger as well - you would use the @ApiModelPropertyOptional() decorator on the attributes that are flagged as @IsOptional(). This way,

This would look something like this:

export class UpdateUserDTO {

   @IsOptional()
   @IsString()   
   @ApiModelPropertyOptional({ type: 'string' })
   firstname?: string;

   @IsOptional()
   @IsString()
   @ApiModelPropertyOptional({ type: 'string' })
   lastname?: string;

   // additional attributes that may be set optionally here
   
   @IsString()
   @MinLength(8)
   @ApiModelProperty({ type: 'string', minLength: 8 })
   password: string;
}

What do you think about this? Or am I missing something crucial here?!
Of course, the corresponding Entity class may needs to have optional attributes as well (e.g., it may be the case that the firstname will never be set) - or you use default values from TypeORM..

I would love to hear your thoughts on this...

All the best

Hi Kelvin,

First things first congratulations for such good work.

I updated your project to version 6.9.0 and create a repo below If you want to use it somehow

https://github.com/RELATO/nest-ideas-api.git

Thank you

Property 'intercept' in type 'LoggingInterceptor' is not assignable to the same property in base type 'NestInterceptor<any, any>'.

Apollo has released their best practices guide for GraphQL based on their work with hundreds of organizations. One of those principles is that we should use one graph. When I asked online about this I was told that all the big kids are using one schema for all queries, types, and mutations. I'm not sure about resolvers yet but my impression is that one page does it all for all modules. So it lives at the root level. Once source of truth.

You are breaking the graph into their relevant modules as we do with everything else including REST. This architecture should probably be re-examined.

Meanwhile, I'm trying to deal with a mental breakdown from trying to get my head around all of GraphQL in one super module. :-)