Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3주차 과제] 서지현 #44

Open
wants to merge 67 commits into
base: ji-hyeon97
Choose a base branch
from

Conversation

ji-hyeon97
Copy link

이번 주에 어떤 작업을 했는지 설명해주세요.

  1. 중고거래 글쓰기(다중 이미지 업로드) API 구현
  2. 상품정보 수정 및 삭제 API 구현
  3. 좋아요 API 구현
  4. 개인 정보 수정 API 구현

특히 어떤 부분을 리뷰받고 싶나요?

  1. 이번 과제하는 것에 있어서 멘토님 께서 생각하는 erd와 각각의 엔티티들의 연관관계(단방향, 양방향)이 궁금합니다.
  2. 현재의 좋아요 API의 경우 응답 메시지로 [완료/취소] 의 응답메시지가 제공됩니다. 허나 페이스북이나 인스타그램에서 알 수있듯이 좋아요 클릭 한경우 옆에 총 좋아요 숫자가 +1 올라가거나 -1 감소할 수 있습니다. 좋아요 api를 수정하여 응답메시지를 총 좋아요 개수를 반환하는 api를 만들 생각입니다. 여기서 만일 client가 좋아요 클릭(get) -> 백엔드에서 좋아요 총 개수 응답 dto 반환 -> 여기서 front는 get요청만 했는데 어떻게 바로 화면에 반영이 되게 되는지 궁금합니다. 제 생각에는 client가 좋아요 클릭(get) -> 백엔드에서 좋아요 총 개수 응답 dto 반환 -> front 새로고침 요청(get) 의 과정이 되어야 된다고 생각합니다. 새로고침 요청을 하지 않고 화면에 총 좋아요 수가 보이는 개념이 궁금합니다.

이번 주는 어떻게 학습했나요? 아래 질문에 짧게 답변주세요!

이번 주에 학습에 투자한 시간

  • 하루에 3시간 정도(??) 꾸준히 하였습니다.

학습 하면서 좋았던 점과 아쉬웠던 점

  • 야생형으로 구글링하며 기능에는 문제가 없도록 각종 API 를 구현하였습니다. (여러개의 이미지 데이터를 다루는게 조금 흥미로웠습니다)
  • 개념적으로 공부를 해야되는 부분이 많이 있습니다(jpql 쿼리 작성법, JPA개념)
  • 로컬에서 week3브랜치를 carrotMarket브랜치로 merge한 뒤 원격으로 push하고 local에서 week3브랜치를 에서 지운뒤 원격 week3 또한 지웠는데 pr 기록은 남을줄 알았는데 close된다는걸 알게되었습니다 ...ㅎ

어려움을 겪는 부분

  • 처음에는 user, board, item 의 3가지 엔티티를 설정하였습니다. 왜냐하면 중고거래 글쓰기라는 하나의 게시판이 있었고 이를 도메인이라고 생각했습니다. 한 명의 사용자는 여러개의 게시글을 작성할수 있고(일대다) 하나의 게시글은 하나의 상품정보를 가지고 있다(일대일) 허나 이는 코드작성하기에 불편 하였고 user 와 item 엔티티 만으로도 화면을 만들기에는 적절하였습니다. 따라서 화면에 종속되어 있는 board 엔티티를 사용하지 않았습니다.
  • 상품 수정 및 삭제시 이미지 데이터의 경우 s3 버킷 이미지도 수정 및 삭제가 되도록 구현하였습니다.
  • 아직은 이해를 잘 못하지만 좋아요 기능에서 발생할 수 있는 동시성 이슈를 알아보고 싶습니다.

스터디 개선되었으면 하는 점

  • X

Copy link
Collaborator

@won983212 won983212 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

연관관계

저도 ERD가 지현님이랑 거의 비슷하게 나올 것 같습니다. 다만 Items부분의 likes와 images 없이 단방향으로 구성할 것 같습니다. 왜냐하면 양방향 없이도 충분히 낮은 복잡도로 좋아요를 구현할 수 있기 때문입니다. 저는 개인적으로 단방향 -> 양방향으로 전환했을 때 코드 복잡도가 크게 낮아진다면 사용을 고려합니다. 대부분은 단뱡항으로 매핑합니다. 이건 좀 개인적인 취향인 것 같습니다.

좋아요 반영 문제

Client 좋아요 클릭 (post) -> Spring이 좋아요 개수 반환 -> 반환받은 요청(좋아요 수)을 client에 반영

이런 메커니즘이 될 것 같습니다. get이든 post든 axios같은 라이브러리를 사용해서(fetch등을 사용할 수도 있습니다.) 서버로부터 반환값을 돌려받고, 그 반환값을 client에 즉시 반영합니다. 반영하는 과정은 순수 html이라면 js DOM으로 할 수 있고, react같은 프레임워크에서는 state등을 변경해서 반영할 수 있겠습니다.

그런데 이런 방식으로 하면 약간의 딜레이가 생깁니다. 그래서 제가 예전에 구현했을 때는 client에서 좋아요 수 response를 받기 전까지 가짜 데이터를 보여주는 방식을 사용했습니다. (아래 2번 과정이 추가된 것입니다.)

  1. Client 좋아요 클릭
  2. 클릭과 동시에 client에서는 좋아요 +1 반영
  3. 이후 Spring이 좋아요 개수 반환
  4. 반환받은 요청(좋아요 수)을 client에 반영

더 나아가서는 Redis를 도입해서 좋아요를 db에 바로 반영하기전에 캐싱하고 batch처리해보는 방법도 생각해볼 수 있을 것 같습니다.

board 엔티디

말씀하신 방식대로 해도 크게 문제되진 않을 것 같습니다. 다만 요구사항이 달라지면 board 엔티디가 필요할 것 같습니다. 예를 들면 1개의 게시글에 여러 개의 상품이 등록될 수 있다, 게시글에 상품 뿐만 아니라 추가적인 칼럼이 필요하다 정도입니다.
향후 확장성을 고려한다면 board를 따로 만드시걸 권장합니다. 물론 마이그레이션이 비교적 간단하고 수정 소요가 크지 않다고 판단되신다면! 그때 필요할 때 만드셔도 상관 없을 것 같습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants