멤버 서비스에 jwt 인증 다넣었다가
이런 의문이 들었음
"만약 여러 요청에 대해 인증인가가 많아지면 멤버서비스 자체가 비대해지는데 어떡할래? 유지보수 감당됨?"
그래 나눠보자
나누니까 개졷됨
jwt에 쓰는 userdetail 인터페이스를 구현해야하는데
멤버 엔티티가 필요함
오호 그럼 멤버서비스에서 엔티티를 반환해야하나 dto를 반환해야하나?
ㅅㅂ 굳이 엔티티 반환할꺼면 인증서비스에도 엔티티폼이 갖춰져야하는데 그럴꺼면 서비스 왜 나눔?
아 그럼 dto? 에휴 필요한 dto 무한대로 만들꺼냐??
아 공통모듈로 가야겠네
이런 자잘한 고민들이 수도없이 쏟아져나옴
죽고싶다
jwt에는 멤버 id 값만 저장하고 member 엔티티 수정해야 할때만 JpaRepository.findById 사용하고, member 엔티티 수정할 필요 없이 연관 엔티티 생성할 때 member 엔티티 넣어야해서 필요한 경우에는 JpaRepository.getReferenceById 쓰면 db 조회 없이 프록시 객체 만들어줘서 편함 jwt userdetail에도 마찬가지로 멤버 엔티티 넣지 말고 멤버 id만 들고있게 하던가 아니면 getReferenceById로 프록시 객체 만들어서 들고있으면 되지 않을까 싶은데
userdetails 쓴다는게 spring security 쓰는거 같은데 3번째줄이 잘 이해가 안가네 어차피 인증 인가는 시큐리티 필터 체인이 다 처리할건데
getReferenceById 이건 언제쓰냐? findById보다 성능이 빨라서 쓰는거임?
JpaRepository.save 호출하려면 외래키 있는 엔티티들 다 들고있어야 되잖아 예를들어 like 테이블 안에 memberId랑 articleId를 들고있는데 이걸 jpa 엔티티로 표현하면 Like 클래스가 Member 객체랑 Article 객체를 들고있어야 되는데 요청으로 넘겨받는건 각각의 id값이면 memberRepository랑 articleRepository에서 각각 실제로 쿼리를 날려서 실제 엔티티 값을 불러올게 아니라 getReferenceById 쓰면 id 값만 들고있는 프록시 만들어주니까 select 쿼리 없이 바로 like 테이블에 insert 날릴 수 있는거지
대신에 각각의 id 값으로 실제 member 테이블 article 테이블에 값이 없으면 외래키 제약조건때문에 오류 발생하긴 할거고