[강대원] sprint11#34
Hidden character warning
Conversation
There was a problem hiding this comment.
Like(좋아요 내역)이 게시글/상품 으로 나뉘어져 enum(상품,게시글)으로 도전해보았는데, 각각 테이블의 FK가 필요하다는 에러로 결국 아래와 같이 상품에 좋아요를 누르면 게시글의 좋아요가 아니므로 postId가 null 이 있을수 밖에 없는 형태로 진행했습니다.
한때는 null이 있으면 안된다는 강박에 상품의 좋아요와 댓글, 게시글의 좋아요와 댓글 이런식으로 하면 좋을거같다는 생각이 들었는데, 이러면 null이 생기진 않지만 테이블이 너무 많아진다는 단점이 발생하여, 오히려 null이 있더라도 테이블을 적게, 관리하기 쉽게 하는게 좋다고 생각이 들어서 진행하게되었습니다.
여담이지만, 질문을 하실 때는 문장을 이해하기 쉽게 끊어서 작성해주시면 좋을 것 같습니다. 문맥을 파악하는데 어려움이 있습니다.
이해한 부분으로 얘기해보자면 좋아요를 PostLike와 ProductLike로 구분하면 테이블이 너무 많아질 것 같아서, 두 테이블을 FK로 참조하는 각각의 column을 추가해서 Like 모델로 정의했다는 뜻으로 받아들였습니다.
우선 여기서 짚고 넘어갈 부분이 몇 가지 있다고 생각되네요.
- "테이블이 너무 많아진다는 단점"에서 '너무'의 기준이 어느 정도인가요?
- 테이블이 1개에서 2개로 늘어나면 '너무 많이' 늘어나는 건가요?
- Like 테이블을 분리하지 않고 하나로 통합하면 정말 관리가 쉬워질까요?
- 상품을 조회하는 상황을 가정해봅시다.
- 상품을 조회할 때 게시글의 좋아요까지 파악해야 할 필요가 있을까요? 이 반대의 경우는 어떨까요?
- 상품 목록 + 상품 좋아요를 조회할 때 좋아요 테이블이 통합된 상황과 분리된 상황에서 조회하는 raw query를 작성해보면 어떻게 될까요?
테이블의 통합과 분리의 경우 참조해야 하는 테이블의 수가 많지 않다면 이번에 대원님이 시도하신 것처럼 연관된 각 테이블을 참조하는 FK column을 추가하는 방식으로도 접근할 수 있고, target_type과 target_id의 조합으로 어떤 테이블과 엮어서 봐야하는지를 로직상으로 구분할 수도 있고, 테이블 자체를 다 나누어버리는 방법도 모두 가능합니다.
어떤 방식이 적절할지는 '데이터의 성격'과 사용되는 상황(묶음 단위)에 따라 달라질 수 있습니다.
Product와 Post가 같은 성격의 데이터가 아니라는 점, 좋아요 데이터를 조회할 때 작성해야 하는 쿼리의 모양 및 성능을 고려하면 이 경우는 Like 테이블을 분리하는 방식이 더 나은 결정이라는 생각이 듭니다.
그리고 Bearer 토큰 방식에서는 .http 파일을 만들어 헤더에 토큰을 추가해 테스트하는데, 쿠키 방식일 때는 어떻게 확인하는지 궁금합니다!
말씀하시는 http 파일(아마 Webstorm?)에서는 처리하는 방식이 있을 겁니다. curl이나 HTTPie, Postman, Insomnia 등의 HTTP 클라이언트 도구에서는 다 쿠키 request를 처리할 수 있는 방식을 제공하고 있거든요.
우선 여기까지가 질문과 관련된 내용입니다.
그리고 추가로 말씀드리고 싶은 내용은 이번 과제에서 NestJS를 사용하셨는데, 전반적으로 NestJS의 기능을 제대로 활용하지 못하고 있는 상태라고 생각됩니다. 특히
- NestJS에서 express를 직접 import하는 점
- 코드 여기저기서 Prisma에 직접 접근하고 있는 점
- 제게 말씀하셨던 NestJS를 사용하려는 이유 중 '로직 분리가 용이하다'는 장점을 전혀 활용하지 못하고 있습니다.
- NestJS의 Entity와 Prisma와의 통합이 떨어진다 => NestJS Entity의 구현체가 비어있으면 안 됩니다.
1과 2 모두 같은 맥락입니다. NestJS의 특징이나 강력한 장점인 '추상화'를 제대로 활용하지 못하고 있다는 점이죠.
| preflightContinue: false, | ||
| optionsSuccessStatus: 204, | ||
| }); | ||
| app.use('/uploads', express.static(join(__dirname, '..', 'uploads'))); |
There was a problem hiding this comment.
static 처리를 하고 싶은 거라면 nest에서도 제공하는 모듈이 있습니다.
| const user = await this.prisma.user.findUnique({ | ||
| where: { | ||
| email, | ||
| }, | ||
| }); |
There was a problem hiding this comment.
만약 ORM 라이브러리를 prisma에서 교체하는 상황이 온다면 어떻게 될까요?
| @Param('postId') postId: string, | ||
| @Request() request: { user?: { userId: string } }, | ||
| ) { | ||
| const userId = request.user ? request.user.userId : null; // 로그인하지 않는 경우 좋아요 false 처리 |
| @Body() updatePostDto: UpdatePostDto, | ||
| @Request() request: { user?: { userId: string } }, | ||
| ) { | ||
| if (!request.user) throw new UnauthorizedException('로그인이 필요합니다.'); |
| updatePost( | ||
| @Param('postId') postId: string, | ||
| @Body() updatePostDto: UpdatePostDto, | ||
| @Request() request: { user?: { userId: string } }, |
There was a problem hiding this comment.
typing 방식도 그렇고 controller에서 계속 request를 참조하는 방식은 별로 좋은 접근은 아니라고 생각합니다.
NestJS를 유지보수하기에 용이하다는 장점이라고 언급하셨던 decorator를 적용해보시면 좋을 것 같습니다.
2 participants
공통
백엔드
주요 변경사항
멘토에게
추후 댓글 관리, 이미지 관리, 사용자 관리 기능을 추가하고, Swagger의 Bearer 토큰 입력 기능과 문서를 완성할 예정입니다.
현재는 Bearer 토큰 방식으로 인증을 처리하고 있지만, 이후에 쿠키 방식도 도입해볼 계획입니다!