어느덧 이번 부트캠프도 마지막을 달리고 있다 ! 아직 3주 가량 남긴했지만 슬슬 마음의 준비를 해야할때가 된 것 같다 !
이번 프로젝트는 B2B Saas 서비스를 만든다! 다른 백앤드 개발자를 대상으로 개발에 도움이 되는 대기열 관련 서비스이다.
흔하지않는 프로젝트여서 회의 내용부터 어려웠지만 조금씩 공부해나가는 중이다.
일단 나는 인증, 인가 부분을 맡게 되었다.
msa에서의 인증/인가
우선은 간단하게 회원가입과 로그인을 구현하는게 내가 맡은 부분인데, 아직 security를 제대로 공부하지못한점 + 모놀리식이 아닌 msa 구조인 점 등으로 조금은 어려운것(?) 같다.
모놀리식 구조라면 auth에서 인증과 관련된 내용 user에는 사용자와 관련된 api 호출을 했겠지만 auth와 user가 각각 다른 어플리케이션에 있는 msa 구조 상 꼭 auth로 분리해야할 것 같은 부분만 auth로 빼서 필요시 feign을 통해 호출 후 사용할 예정이다.
처음으로 jwt를 이용해봤다.
회원가입을 진행하게되면, pw는 service 단에서 암호화를 거쳐 user 객체 pw필드에 저장되고 auth에 있는 createAccessToken에 사용자 이메일을 파라미터로 넘겨 토큰을 생성한다.
jwt 토큰은 사용자 정보를 담는다는 특징이 있다.
이후 이 토큰을 응답 response의 헤더에 담는 과정이 있다.
첫번째 리뷰
팀원분들이 리뷰를 잘해주셔서 많이 배우게 된다.
위의 과정을 통해 처음으로 코드에 대해 리뷰를 들었다.
처음 구조
userController -> userService -> feingClient -> authController -> authService
첫 구조의 경우 user controller 단에서 모든 작업을 다하고 jwt 토큰 발급만 auth package를 이용하려고 했다.
하지만 그렇게 되면 거의 모든 책임을 user에서 갖게되고 Auth 서비스가 있으나마나한 구조가 되버려서 로직을 바꾸게 되었다.
바뀐 구조
authController -> authService -> feignClient -> userController -> userService
이제 Auth에서 사용자에 대한 정보를 검증하고 jwt 까지 발행해준다. user의 정보가 필요하거나 user에대한 정보를 저장할때만 user 서비스를 feign으로 호출한다.
다음과 같은 시퀀스로 로직을 변경했다.
두번째 리뷰
두번째 리뷰는 @valid의 사용, Binding Result의 사용이 어떤지에대해 리뷰를 받았다!
@Valid, BindingResult
dto 를 주고받을때, @email 이나 @NotNull 같은 어노테이션을 사용해서 validation을 진행하려고 했다.
controller 단에서 service로 dto를 던지는 매개변수에 valid를 달아 validation 체크를 하고 BindingResult를 사용해 검증로직을 구현했다.
bindingResult에 해당 오류가 있을시 에러메시지를 가져와 faailResponse로 만들어줬다.
세번째 리뷰
두 번째 리뷰의 사진 속
FailedResponseBody failedResponseBody = new FailedResponseBody ()
부분에 대해 리뷰가 있었다.
여기서 또 새롭게 @ControllerAdvice에 대해 알게되었고, @ExceptionHandler와 함께 이번주 내로 프로젝트에 적용해볼 예정이다.
이어지는글
