학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요 선생님! 지난번에 남겨주신 답변내용을 보면서 전략도입의 배경부터 처리과정까지 복기해보았습니다. 그러다가 의문이 생긴 점이 있습니다. 1) 의문점 Request Collapsing, 캐싱중복적재를 제외하고 캐싱하여 데이터를 추출하는 과정만을 보았을때, 원본과 캐싱 데이터 모두 Redis에서 추출해오는 것인데, 원본추출과 비교하였을때 과정적으로 어떠한 차이점이 추가적으로 있있기에 별도의 과정으로 간주하는 것일까? 즉, "캐싱하여 가지고 오는 과정"과 "원본 데이터 추출"을 따로 보고 계셨기에, 어떠한 차이점이 있는지 의문점이 들었습니다. 2) 의문점이 생긴 이유 단순하게 간략히 말씀드리자면, 조회수 원본데이터는 Redis에서 가져오는 조회수이고, 캐싱해서 가져오는 것 역시 Redis에서 가져오는 조회수로 보여집니다. 원본데이터가 MySQL과 같은 디스크 조회 비용이 큰 저장소에 들어있는 것이 아니라, 동일한 In Memory database인 Redis에서 가져오는 것이기에 성능/비용적으로 캐싱 데이터를 가지고 오는 것에 큰 이점을 느끼지 못하였습니다. 세부적으로 살펴보았을때, ViewClient에서 원본 데이터를 가지고 오는 경우 아래 로직을 통해 Redis에서 추출합니다. articleViewCountRepository.read(articleId); 이떄 key는 view::article::#articleId::view_count 입니다. ViewClient에서 Aspect를 처리하여 캐싱 데이터를 가지고 오는 경우 Redis에서 추출합니다. 이때 key는 articleViewCount::#articleId입니다. 이 과정에 대해 캐싱을 하는 목적을 생각해보았을때(=원본데이터 추출에 시간이 오래 걸릴 경우 성능이 빠른 다른 데이터저장소를 운용하여 이곳에서 데이터를 추출해오기 위함), 동일하게 Redis에서 추출하는 데이터임에에도 key를 별도로 운용하고, 데이터를 추출하는 과정도 다르게 가져가는(간주하는) 이유가 무엇인지 궁금하여 문의코자 합니다(물론 전체 로직을 살펴보았을때는 기존 대비 중복적재/Request Collapsing 과정을 추가하였기에 당연히 성능적인 이점이 존재하겠지만, 데이터를 가져오는 과정 그 자체만을 보았을때는 의문점이 들었습니다). 이게 데이터를 추출하는 과정이 다르기에, 동일한 key로 운용하면 실무적으로 로직이나 key관리방안이 복잡해져서 관리의 효율화를 위해 나누는 것일까요(즉, 기존과 달리 분산락도 사용하고 중복적재를 방지하기 위해 이용하므로 목적 자체가 다르기에 key 포맷 및 캐싱을 별도로 운용하는 것으로 이해하는 것이 적절한지)? 제가 캐싱의 목적 부터 잘못 이해하고 있는 것일 수 있고, 실무적으로 비용/성능적 유리하다는 의미가 무엇인지 잘못 이해하고 있는 것일 수 있다고 생각하고 있습니다. 그렇기에 챗지피티에게 물어보기보다는 실무적으로 경험이 풍부하시고 그만큼 검증된 선생님의 판단이 더 정확하고 궁금하여 질문드리게 되었습니다. 바쁘신데도 항상 성심성의껏 답변해주시는 선생님께 감사의 말씀 드립니다. 이효균 드림.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 프로젝트 지웠다가 처음부터 다시 해보기도 하고 질문글 따라 보면서 해봐도 에러가 떠서 어떻게 해야할지 모르겠어요.. .
Custom Repository 부분에서 에러가 나서 해결 하긴 하였으나 맞는 과정인지는 잘 몰라 문의드립니다. 강의에서 사용하는 @EntityRepository방식은 구버전(0.2.x) 방식으로 최신버전에서는 제거되었습니다. 강의 코드를 그대로 따라하면 ... is not a function같은 에러가 발생합니다. 그래서 user.repository.ts, auth.modules.ts 수정, auth.service.ts를 수정 1. user.repository.ts 수정 1. user.repository.ts 수정 Repository를 일반 서비스로 만들기 위한 핵심 작업입니다. 수정 내용: @EntityRepository(User) 데코레이터를 삭제하고 @Injectable()을 추가했습니다. Repository 클래스를 초기화하기 위해 constructor (생성자)를 추가하고, 그 안에서 super()를 호출했습니다. // src/auth/user.repository.ts import { Injectable } from '@nestjs/common'; import { DataSource, Repository } from 'typeorm'; import { User } from './user.entity'; // ... @Injectable() // ✅ 변경 export class UserRepository extends Repository<User> { // ✅ 생성자 추가 constructor(private dataSource: DataSource) { super(User, dataSource.createEntityManager()); } async createUser(/* ... */): Promise<void> { // ... } } 2. auth.service.ts 수정 -> providers 배열에 UserRepository를 추가했습니다. 이유: providers 배열에 등록해야만 AuthModule이 "아, UserRepository라는 서비스를 모듈로 포함시켰습니다. // src/auth/auth.module.ts import { UserRepository } from './user.repository'; // ... @Module({ imports: [TypeOrmModule.forFeature([User])], controllers: [AuthController], providers: [ AuthService, UserRepository, // ✅ UserRepository를 providers에 등록 ], }) export class AuthModule {} 3.auth.service.ts 수정 > 서비스에서 Repository를 주입받는 방식을 변경합니다. 수정 내용: @InjectRepository(User) 데코레이터를 삭제하고, 생성자에서 UserRepository를 직접 타입으로 선언하여 주입받습니다. 이유: UserRepository는 이제 마법 같은 존재가 아닌 일반 서비스이므로, 다른 서비스를 주입받을 때와 똑같이 클래스 이름만으로 간단하게 주입받을수 있습니다. // src/auth/auth.service.ts import { Injectable } from '@nestjs/common'; import { UserRepository } from './user.repository'; // 🗑️ import { InjectRepository } from '@nestjs/typeorm'; <- 삭제 @Injectable() export class AuthService { constructor( // 🗑️ @InjectRepository(User) <- 삭제 private userRepository: UserRepository, // ✅ 직접 주입 ) {} async signUp(/* ... */): Promise<void> { return this.userRepository.createUser(/* ... */); } } 일단 이런식으로 수정했는데 이 과정이 맞는지는 잘 모르겠습니다! 강사님이나 따로 혹시 올라와 있는 코드가 있다면 참고해보겠습니다!
상위 레이어의 정보를 알면 안되기 때문에, repository에서는 dto가 아니라 모델을 받아야 한다고 하는데, 모델의 타입이 어떻게 되는 건가요? 그리고 위의 예제에서 service의 create 메서드는 아래와 같이 dto를 인자로 넘겨주고 있는데, 그러면 dto로 타입을 맞춰야 하지 않나요? async create(createPostDto: CreatePostDto): Promise<Post> { const post = this.postRepository.create(createPostDto); return this.postRepository.save(post); } 그리고 글 수정 api 컨트롤러에서 put 메서드를 사용하신 것 같습니다. @Put(':id') update( @Param('id', ParseIntPipe) id: number, @Body(ValidationPipe) updatePostDto: UpdatePostDto, ) { return this.postService.update(id, updatePostDto); } 제가 생각했을 때는 일부분을 수정하는 케이스니까 restful 하도록 바꾼다면, patch 메서드가 적합하다고 생각이 드는데, 이해한게 맞을까요? 감사합니다.
21:09 지금 까지 이해한 포인터의 방법은 주소 사용할때는 & 또는 생략, 값을 사용할때는 *로 이해하고 있습니다. 해당 printf("%s\n", arr[0][0]); 라는 구문에 질문이 있습니다. 포인터 변수로 해당 문자열의 주소를 각 맵핑하였고 배열에 맞게 출력하는걸로 해석이 되는데 이때 왜 값을 안 가져오고 주소를 가져오는지 궁금합니다. 또한 %s로 출력하고 해서 주소대신에 값으로 가져오는지 궁금합니다.
nest.js에서의 레이어드 아키텍처 구조 에 궁금한 점이 생겨 질문을 남깁니다 각 계층별 실제 구현 파일을 아래와 같이 이해하면 될까요? repository 와 entity 가 정확히 어떤 계층에 속하는지 궁금합니다. Presentation Layer controller.ts Application Layer service.ts Domain Layer repository.ts entity.ts Data Transfer Object dto.ts
유형 9번에서 처음에 Child obj = new Child(); 의 뜻이 Child 타입의 새로운 생성자를 생성하는 것이고, 이 생성자의 자식 class로 갔는데, 생성자가 없고, 부모에도 생성자가 없어서 출력되는 값은 없는 것이고, 그 뒤의 obj.display()코드를 실행해 display의 메서드에서 부모로부터 상속받아 Parent display, Child display가 답이 되는것이 맞을까요?
안녕하세요. 궁금한게 있어서 질문 드립니다. domain 패키지에 entity를 위치 한다고 했을때 주석이라고 말씀하신 어노테이션 JPA @Entity를 만들어서 Member로 정의 그리고 mongo DB도 필요해서 @Document를 정의해서 domain 패키지에 위치 시켜 Member로 정의 이처럼 같은 도메인이 서로 다른 DB로 사용 될때 어떻게 도메인으로 정의해야할지 궁금합니다. 그리고 이름이 중복되는 현상도 발생하기도 합니다. 그렇다고 OracleMember, MongoMember로 지을수도 없는것같습니다. 제 생각은 Member라는 도메인이 Domain 패지키에 별도로 나와서 adapter 안에 JPA Persistent의@Entity로 정의된 클래스와 Mongo Persistent의 @Document로 정의된 클래스가 위치 되어야한다고 생각하는데 어떤 의견이신지 궁금합니다.
