-
Notifications
You must be signed in to change notification settings - Fork 22
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
base: ji-hyeon97
Are you sure you want to change the base?
[3주차 과제] 서지현 #44
Conversation
There was a problem hiding this 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번 과정이 추가된 것입니다.)
- Client 좋아요 클릭
- 클릭과 동시에 client에서는 좋아요 +1 반영
- 이후 Spring이 좋아요 개수 반환
- 반환받은 요청(좋아요 수)을 client에 반영
더 나아가서는 Redis를 도입해서 좋아요를 db에 바로 반영하기전에 캐싱하고 batch처리해보는 방법도 생각해볼 수 있을 것 같습니다.
board 엔티디
말씀하신 방식대로 해도 크게 문제되진 않을 것 같습니다. 다만 요구사항이 달라지면 board 엔티디가 필요할 것 같습니다. 예를 들면 1개의 게시글에 여러 개의 상품이 등록될 수 있다
, 게시글에 상품 뿐만 아니라 추가적인 칼럼이 필요하다
정도입니다.
향후 확장성을 고려한다면 board를 따로 만드시걸 권장합니다. 물론 마이그레이션이 비교적 간단하고 수정 소요가 크지 않다고 판단되신다면! 그때 필요할 때 만드셔도 상관 없을 것 같습니다.
이번 주에 어떤 작업을 했는지 설명해주세요.
특히 어떤 부분을 리뷰받고 싶나요?
이번 주는 어떻게 학습했나요? 아래 질문에 짧게 답변주세요!
이번 주에 학습에 투자한 시간
학습 하면서 좋았던 점과 아쉬웠던 점
어려움을 겪는 부분
스터디 개선되었으면 하는 점