import { ApolloDriver, ApolloDriverAsyncConfig as ad } from '@nestjs/apollo'; import { Module } from '@nestjs/common'; import { GraphQLModule } from '@nestjs/graphql'; import { AppController } from './app.controller'; import { AppService } from './app.service'; @Module({ imports: [ GraphQLModule.forRoot<ad>({ // forRoot의 데이터타입지정 <> -> 제네릭 부분 driver: ApolloDriver, autoSchemaFile: 'src/commons/graphql/schema.gql', }), ], controllers: [AppController], providers: [AppService], }) export class AppModule {} import { Field, Int, ObjectType } from '@nestjs/graphql'; @ObjectType() // graphql에서 type을 의미함 예)type Board export class Board { @Field(() => Int) // Int를 import를 해서 사용해야한다 number: number; // ;을 기준으로 구분함 @Field(() => String) // graphql을 위한 용도 writer: string; @Field(() => String) title: string; @Field(() => String) contents: string; } 단순히 graphql shema를 자동생성 해주는 거만 테스트할려고했는데 경로를 잡아주니 에러가나와서 true도 해보고 playground : true도 추가해보고했는데 계속 해서 오류가 나고 계속해서 오류는 type이 존재하지않는다고해서 이유를 모르겠습니다 Argument of type '{ driver: typeof ApolloDriver; autoSchemaFile: string; }' is not assignable to parameter of type 'ApolloDriverAsyncConfig'. Object literal may only specify known properties, and 'autoSchemaFile' does not exist in type 'GqlModuleAsyncOptions<ApolloDriverConfig, GqlOptionsFactory<ApolloDriverConfig>>'.ts(2345)
해당 강의에서 product service의 create 함수를 아래와 같이 코딩하는 것을 가르쳐주셨는데요. 아래 코드에서 const tags = [...prevTags, ...newTags.indentifiers]; 부분에서 prevTags에도 .identifiers가 붙어야 될 것같다는 생각을 했습니다. prevTags는 this.productsTagsRepository.find 함수를 통해서 찾아오는데, 이는 where 조건문에 의해 name이 tagNames인 것을 찾아내어 productTags의 프로퍼티인 id와 name을 둘다 return 하지 않나요? 이전 조회API를 만드는 강의에서도 find 함수를 통해 id만 가져오는 것이 아닌 다른 칼럼들도 모두 가져왔었습니다. 그런데 prevTags 뒤에 .indentifiers를 붙이니 에러가 뜨더라구요... 분명 조회API 강의에서는 find를 통해 모든 칼럼을 다 가져왔던것 같은데, 왜 이번에는 똑같은 find 함수를 통해 id만 리턴이 되는 건가요? async create({ createProductInput }: IProductServiceCreate): Promise<Product> { const { productSalesLocation, productCategory, productTags, ...product } = createProductInput; const result = await this.productsSalesLocationService.create({ productSalesLocation }); const tagNames = productTags.map((el) => el.replace('#', '')); const prevTags = await this.productsTagsRepository.find({ where: { name: In(tagNames) }, }); const temp = []; tagNames.forEach((el) => { const isExist = prevTags.find((prevEl) => el === prevEl.name); if (!isExist) temp.push({ name: el }); }); const newTags = await this.productsTagsRepository.insert(temp); const tags = [...prevTags, ...newTags.identifiers]; const result2 = this.productsRepository.save({ ...product, productSalesLocation: result, productCategory: productCategory, productTags: tags, }); return result2; }
안녕하세요! 강의 잘 듣고 있는 학생입니다. 1:1관계등록 강의에서는 product sales location 관계를 등록할 때는 따로 sale location에 대한 모듈 파일과 리졸버 파일은 만들지 않고 서비스 파일만 만들어서 관계를 등록하였는데, 1:다 관계등록 강의에서는 product category에 대한 모듈파일과 리졸버 파일까지 만들어 관계등록을 하는 것으로 가르쳐주셨습니다. 코드 구성은 크게 다르지 않은 것 같은데, 카테고리 관계등록 강의에서는 일대다 관계이기 때문에 리졸버와 모듈파일까지 만들어서 관계등록을 하는 것인가요? 그렇다면 이유를 좀 알 수 있을까요..? 코드 구성은 비슷하고, 차이라고 할 것은 1대1이냐 1대다이냐 밖에 없는 것 같은데 이렇게 모듈파일을 만들어주고 안만들어주고의 차이가 발생하는 이유가 이해가 안가서요 ㅠ
안녕하세요. 해당 강의를 보다가 궁금증이 생겨서 글을 남기게 되었습니다. Entity는 디비 테이블의 컬럼들을 작성(실제 컬럼 및 디비에 없는 컬럼들까지)하고 Dto는 요청에서 받는 타입들을 작성하고 해당 타입들을 Controller 전에 검증해주는 클래스라고 알고 있었습니다. 궁금한건 아래 2가지 인 것 같습니다. Entity는 디비 테이블의 컬럼을 / Dto는 타입 검증을 위한 데코레이터들을 작성하는 클래스로 분리되는 개념으로 생각해왔었는데 잘 못 생각하고 있었던건가요?? 만약, Dto 클래스에 있는 컬럼들을 생략하면 nickName?: string; 처럼 선택적 옵션들과 @IsString()등 타입 검증을 해주는 데코레이터들을 전부 Entity에 작성해주는 건가요?? 저는 Entity는 건들이지 않고 Dto에서 선택적 옵션과 타입 검증들의 데코레이터를 사용하고 있었어서 궁금해졌습니다..!
발생하는 장점을 다음과 같이 설명해주셨는데요. 1. new 한 번으로 모든 곳에서 재사용 가능 2. 의존성 주입으로 몽땅 한꺼번에 변경 가능 다음과 같은 예시를 들어주셨는데, ProductController의 constructor에서 this.cashService = new CashService() 와 같은 사용을 하면 constructor에서 변경점을 가져가고 해당 클래스의 모든 함수에서는 this.cashService를 통해 사용할 수 있고요. class ProductController { cashService constructor() { this.cashService = new CashService() } } CashService 대신 CashService2로 변경하고 싶을때는 다음처럼 변경하면 2번 장점도 동일해지구요. class ProductController { cashService constructor() { //this.cashService = new CashService() this.cashService = new CashService2() } } 의존성 주입을 통해 얻을 수 있는 이점은 위와 같은 재사용이나 변경에 대한 장점보다도 말 그래도 의존성을 없애는 것에 있다고 보는데요. 의존성 주입을 통해 ProductController에서 구현체인 CashService에 대한 의존성을 없애고, 외부에서 CashService에 대한 의존성을 가져갈 수 있게 되니까요. CashService에 대한 코드의 변경으로 인한 ProductController의 코드 변경이 발생하지 않도록 하는 것이 의존성 주입의 핵심이라고 보는데, tight-coupling을 왜 loose-coupling으로 변경해주어야 하는지에 대한 설명은 없었던 거 같아서요. 이 부분에 대해 어떻게 생각하시는지 궁금합니다!
안녕하세요? 인프런 수업자료 페이지에서 받은 파일이 모두 비어있어 커뮤니티에서 검색을 해보니 강사님께서 PDF파일 링크를 올려주신 답변을 찾았는데 PDF파일은 중간중간 글자가 짤리는부분이 좀 있는 듯 하여 DrawIo로 XML파일 불러와서 봐보고싶은데 XML파일은 링크를 찾을수가 없더라구요~ XML파일도 링크 공유해주시면 감사하겠습니다. Nest 처음 공부하는데 강사님 강의 정말 도움 많이 되고 있습니다. 감사합니다!
TypeORM을 이용한 소프트 삭제에서 softRemove와 softDelete를 이용하는 방법 두가지가 있는데, 강의에서는 softDelete를 이용하는 경우에 대해 설명을 해주셨는데요. softRemove를 하는 경우에도 entity에 똑같이 @DeleteDateColumn 으로 deleteAt을 추가해주면 되나요? @RemoveDateColumn은 내장되어 있지 않은것 겉더라구요.. 그리고 softRemove 에서는 .affected 가 안되던데 true 나 false로 리턴받을 수 있는 방법이 있을까요?
터미널에 npm run start:dev 를 입력하면 자꾸 Error: Cannot find module 라는 에러가 뜹니다;; npm를 지웠다 깔기도 하고, node module 폴더를 삭제하기도하고, lock.json 파일을 삭제해보기도 했는데 여전히 계속 에러가 뜨는데 왜 이런건가요?.....
안녕하세요. express 에서 rest 방식에서는 API를 생성할 때, get이나 post 등의 메소드 방식을 정하고 주소를 지정하여 프론트엔드에서 fetch 나 axois 함수에 주소를 기입하여 API 요청을 했었습니다. graphQL 방식의 nestjs에서는 프론트엔드에서 API 요청을 보낼 때 어떤 방식으로 하나요? 따로 주소 같은 것을 지정해주지는 않는 것같은데.. 똑같이 fetch 나 axois 함수를 통해 요청을 하는 건가요?
안녕하세요 원두멘토님ㅎㅎ 이런 에러가 계속 떠서 docs와 스텍오버플로우에 검색을 해보니 Passport-jwt를 import하는 것이 아닌 passport-local을 import하는 것이라해서 했더니 다행히 실행이 됩니다. 수업내용에서는 passport-jwt로만 해도 작동이 잘되는 것 같은데 왜 이런 문제가 생기는 것일까요? 그리고 passport-local로 하면 실제 배포에서는 사용 못하는 것이 아닌지 질문을 남깁니다. p.s 재작년에 코캠2기 수료하고 백엔드를 많이 기다렸는데 이렇게 인프런에서 다시 인강으로 뵙게 되서 너무 반갑습니다
