- 프로젝트명: "뉴스피드 만들기"
- 프로젝트 소개: 내 게시물을 포함한 모든 게시물을 볼 수 있는 공간입니다.
- 시연 영상: https://www.youtube.com/watch?v=DeojTSjR9dY
- 사용 기술: #SpringBoot #JPA #MySQL #Redis
GitHub: https://github.com/k-jaehyun/NewsFeed
ERD 수정
오늘은 오후 회의를 통해 ERD, API 명세에 전반적인 수정 사항이 있었다.
변경된 ERD
처음 ERD를 설계 할 때 Comment 엔터티와 Post 엔터티가 N대M의 관계로 잘못 생각했다. 하지만 다시 생각해보니 Comment는 Post 하나에 속해야 하기 때문에 N대1의 관계였던 것이다!
그렇다면 post_comment 테이블을 추가 생성할 필요 없이 간단하게 구현 할 수 있는 것이다.
수정은 만드는 것보다 힘들다...
구현에 필요한 지식 자체는 어렵지 않았다.(이미 더 어렵게 만들어놨기 때문에)
하지만 이미 코드가 짜여있는 상태에서 엔터티 관계와 다른 코드들을 수정한다는 것은 처음부터 구현하는 것보다 힘들다는 것을 알았다.
신경 쓸게 한두가지가 아니었기 때문이다. 혹시 다른 곳에서 문제가 발생하진 않는지, 엉뚱한 코드가 호출되지 않는지, 쓸모없는 코드가 없는지 등등... 실무에 가면 이런식으로 수정 할 일이 많을까..?
처음부터 면밀히 검토해보고 설계를 해야겠다. 설계의 중요설을 다시 한번 느꼈다.
좋아요 : N대M 관계 -> 테이블생성
어제 구현한 좋아요 기능은 엔터티 내에 좋아요 한 memberId를 저장하는 구조로 구현되었다. 하지만 이것은 메모리를 너무 많이 할당하게 되어, 조회에 많은 시간이 필요로하며 서버 및 DB에 부담이 될 수 있는 문제가 있었다. 그래서 회의를 통해 좋아요 기능에 수정이 필요하다는 의견이 모아졌다.
좋아요는 N대M 관계에 있다.
(Member가 여러개의 좋아요를 누르며, Post에도 여러개의 좋아요가 있다.)
따라서 테이블을 하나 생성하여 1대N관계로 풀어주거나 @ManyToMay 어노테이션을 사용해야 한다. 그렇지만 @ManyToMany 는 개발자에게 혼동을 주기에 충분하기 때문에 테이블 생성을 채택했다.
개발하며 느낀 것들
부모엔터티, 자식엔터티 삭제시 관계를 잘 생각해야겠다.
아직 엔터티가 수정되지 않은 상태에서 게시글 삭제 기능을 만들었을 때(post_comment라는 테이블이 있었을 때), 부모-자식 엔터티 연관관계 때문에 삭제가 수행되지 않는 오류가 있었다.
FK가 없는 Comment 엔터티를 먼저 삭제하려니 오류
오류가 뜬 코드
순서를 수정한 뒤 정상 작동
Spring security 형님은 DTO에 민감하시다.
문제 없는 정상코드라고 생각하고 작동시켰는데, 인증인가에서 문제가 발생했다. 이건 저번 할일 카드 만들기에서 발생한 것과 같은 문제였다.
그런데 이번에는 혹시나 싶어 클래스에서 다른 클래스로 데이터를 return 할 때 DTO에 감싸서 보냈더니 성공했다!
엔터티가 수정되면 테이블에 영향을 줄까봐 굉장히 민감하신가보다.
이번주 내내 고민하던 문제가 해결되어 너무나도 기쁘기 그지없었다.
(이렇게 짧게 썼지만 정말 기뻐서 날뛰었음)
- 231126
내 생각이 맞는건지 검색해보았으나 이런 얘기는 나오지 않았다.
하지만 DTO를 사용한다면
- 보안 및 민감한 정보 보호
- 유연성 (엔터티 구조가 변경시 클라이언트에는 영향을 주지 않고, DTO의 구조만 조정하면 됨)
- 네트워크 트래픽 최적화 (필요한 데이터만 전송하므로 네트워크 트래픽을 최적화)
- 클라이언트와 서버 간의 결합도 감소 (클라이언트는 엔터티의 내부 구조를 알 필요 없이 필요한 데이터만 받아서 사용)
- 231127
알았다!
지연로딩 문제: 엔티티에서 지연로딩을 사용하는 경우, 클라이언트에서 엔티티를 직접 사용하면 지연로딩으로 인한 문제가 발생할 수 있습니다.
여기서 문제가 발생했던 것이다!
fetch type이 LAZY 일 때를 주의해야겠다고 생각은 했지만 직접 마주해보니 생각이 나지 않았었다.
스프링 시큐리티를 이용한 로그인 로직
스프링 시큐리티는 자체적으로 로그인 화면을 출력한다. 하지만 어떻게 내가 만든걸 인식하고 그것으로 대체하는 것이지? 라는 의문을 품고 일단 사용하고 있었는데... JwtUtil에 아래와 같은 코드가 작성되어 있었기 때문이다! 저렇게 써놓으면 로그인 url이 저것으로 설정되는 것이었다. 그동안 유연히 url이 같아서 인지하지 못했을 뿐..!
범접 할 수 없던 높은 산으로만 보이던 Spring security 형님이었는데...
이제는 좀 친숙하게 지낼 수 있을 것 같다
관련 포스팅
Previouse Post
Following Post
