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 문의하기를 이용해주세요. const movieId = request.data.result[Math.floor(Math.random() * request.data .results.length)].id; 부분 작성 후 컴파일 시 리액트에서 Cannot read properties of undefined 에러가 발생합니다. 하나가 아니라 여러개 발생하는데 조치방법이 있을까요?
안녕하세요! 강의 잘 듣고 있는 학생입니다. 1:1관계등록 강의에서는 product sales location 관계를 등록할 때는 따로 sale location에 대한 모듈 파일과 리졸버 파일은 만들지 않고 서비스 파일만 만들어서 관계를 등록하였는데, 1:다 관계등록 강의에서는 product category에 대한 모듈파일과 리졸버 파일까지 만들어 관계등록을 하는 것으로 가르쳐주셨습니다. 코드 구성은 크게 다르지 않은 것 같은데, 카테고리 관계등록 강의에서는 일대다 관계이기 때문에 리졸버와 모듈파일까지 만들어서 관계등록을 하는 것인가요? 그렇다면 이유를 좀 알 수 있을까요..? 코드 구성은 비슷하고, 차이라고 할 것은 1대1이냐 1대다이냐 밖에 없는 것 같은데 이렇게 모듈파일을 만들어주고 안만들어주고의 차이가 발생하는 이유가 이해가 안가서요 ㅠ
발생하는 장점을 다음과 같이 설명해주셨는데요. 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으로 변경해주어야 하는지에 대한 설명은 없었던 거 같아서요. 이 부분에 대해 어떻게 생각하시는지 궁금합니다!
TypeORM을 이용한 소프트 삭제에서 softRemove와 softDelete를 이용하는 방법 두가지가 있는데, 강의에서는 softDelete를 이용하는 경우에 대해 설명을 해주셨는데요. softRemove를 하는 경우에도 entity에 똑같이 @DeleteDateColumn 으로 deleteAt을 추가해주면 되나요? @RemoveDateColumn은 내장되어 있지 않은것 겉더라구요.. 그리고 softRemove 에서는 .affected 가 안되던데 true 나 false로 리턴받을 수 있는 방법이 있을까요?
안녕하세요. 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기 수료하고 백엔드를 많이 기다렸는데 이렇게 인프런에서 다시 인강으로 뵙게 되서 너무 반갑습니다
안녕하세요 강사님! 질문 드리기에 앞서 항상 좋은 강의 감사드립니다! 제가 강의를 수강하면서 의아한 부분이 있었는데요, 바로 OrderResponse에 List<ProductResponse> 를 추가하신 부분 입니다. 이에 따라 OrderResponse의 of() 메소드 안에서 order.getOrderProducts() 를 호출할 수 밖에 없게 되었는데요, 이때 페치조인을 하지 않는 이상 쿼리가 나가게 될 것 같습니다 (지연로딩) 저는 바로 이 측면이 개인적으로 잘못되었다 고 생각하는데요, JPA는 어떤 쿼리가 어느 타이밍에 나가는지를 파악하기 어려워서, 최대한 이 측면을 명확하게 해주는게 필요하다고 생각합니다. 그래서 저의 경우는 서비스 로직에서 사용되는 repository 메소드 들에서만 쿼리가 나가는 경우로 명확하게 제한을 해주는 편 인데요, 이런식으로 서비스 로직이 아닌(정확히는 그 안에서 사용되는 repository메소드) 다른 곳에서 지연로딩으로 인해 쿼리가 나간다면 - 어느타이밍에 어떤 쿼리가 나가는지를 코드만 보고 명확하게 파악할 수 없게 된다고 생각합니다. 그래서 결론적으로 저는 OrderResponse 안에서 order.getProducts()를 호출하여 List<ProductResponse>를 만드는게 적절하지 않다고 생각하는데요, 이부분에 대해 강사님의 생각을 말씀해주시면 감사하겠습니다! 감사합니다.
안녕하세요! 먼저 항상 좋은 강의 감사드립니다!\ 다름이 아니라, 저는 제목대로 , 테스트를 위해서 OrderSerivce의 createOrder의 파라미터로 registerDateTime을 파라미터로 받게 추가한 측면이 개인적으로 적절하지 않다고 생각 하여 질문글을 작성하였습니다. 파라미터를 사용하는 이유는 결국 외부로 부터 값을 받는다는 전제가 깔려있다고 생각하고, 이런 측면에서 보았을 때 요청값으로 시간 값을 받는다고 생각할 수 있습니다. 그렇게 생각을 했을때 개인적으로 2가지 정도의 의아한 점이 발생한다고 생각합니다. 클라이언트로 부터 넘겨받는 시간이 과연 등록 시간이라고 할 수 있는가? (network delay가 있을것 이기 때문) 그렇다고 Controller에서 now() 를 호출한 시간이라는 일종의 고정값을 받을거면 - 파라미터를 선언하는 의미가 있는가? 결론적으로 저는 createOrder의 파라미터로 registerDateTime을 선언하는것이 적합하지 않다고 생각합니다. 하지만 우리의 경우는 tdd로써 테스트를 위해 외부로 값을 추출하였는데 - 이러한 문제가 발생하였으므로, tdd 개발론이 과연 적절한 production code를 만드는게 기여하는가? 라는 측면에서 의문이 듭니다. 나아가 당연히 저의 미숙한 탓 이겠지만, 강의를 진행해주신 방식대로 온전한 비즈니스 로직을 작성하지 않고 , 테스트 - 개발 - 테스트 - 개발... 이런 플로우로 개발을 하는것이 과연 도움이 되는가? 도 조금 의아한 것 같습니다. 어쨌든 여기까지는 저의 순수한 개인적 생각인데요, 이런 부분에 대해서 강사님 께서는 어떻게 생각하시는지 말씀해주시면 정말 감사하겠습니다!
