[✨ feat] 회원가입 시 FCM 토큰 저장 로직 구현 #56
Conversation
jsoonworld
left a comment
jsoonworld
left a comment
There was a problem hiding this comment.
그리고 해당 방식이 동기적으로 구현이 이루어지다보니 아무래도 트래픽이 많이 몰리는 상황에서는 비효율적이라는 생각이 들었어요.
이후 구현할때 메시지 큐를 이용해 비동기적으로 처리하는 것을 고려해보면 좋을 것 같아요..!
운영 서버에서 회원 가입 시 알림 서버로 회원 정보를 즉시 전달하고 처리하는 구조는
처음 구현 단계에서는 단순하고 직관적인 흐름을 제공하지만,
서버 간 직접적인 의존이 생기면서 트래픽 급증 시 병목이나 장애 전파의 위험이 존재하는 것 같아요!.
이처럼 동기 호출의 한계를 인지하시고,
메시지 큐(Kafka, RabbitMQ 등)를 활용한 비동기 방식으로의 전환을 고려하신 점은 정말 멋진 판단 같아요!
만약 메시지 큐 기반으로 구조를 개선하게 된다면,
운영 서버는 회원 가입 이벤트를 발행(Publish) 하는 역할만 수행하고,
알림 서버는 해당 이벤트를 구독(Consume) 하여 필요한 사용자 초기 데이터를 설정하는
리스너(Listener) 또는 이벤트 핸들러의 역할로 변경될 수 있겠죠.
이러한 방식은 서버 간 결합도를 낮추고, 각 서비스가 자신의 역할에 집중할 수 있도록 하여
유지보수성과 확장성 모두를 향상시키는 구조적 이점을 제공할 것 같네요!
특히, 추후 알림 외에 다른 이벤트(예: 첫 스크랩 등록 등)로 확장할 때도
같은 이벤트 스트림을 활용할 수 있어 유연한 아키텍처 설계로 이어질 수 있을 것 같아요!
[추가 제안]
회원 생성 시 설정되는 push_status, account_status 등과 같은 초기 default 값 로직이
현재 외부에서 개별적으로 주입되고 있다면,
이러한 디폴트 설정들을 하나의 객체(UserDefaults 또는 UserCreationPolicy 등)로 분리해 관리하는 것도 고려해볼 수 있을 것 같아요!
이 방식은 디폴트 전략 변경 시 변경 지점을 한 곳으로 제한해
전역적인 정책 관리와 유지보수에 큰 도움이 되며,
추후 테스트 코드에서도 디폴트 전략을 모킹하거나 교체하기도 쉬워질 것 같네요!
마무리
전체적으로 코드에서 객체 간 메시지를 잘 주고받고 있고,
각 계층과 객체들이 자신의 책임에 집중할 수 있도록 구성되어 있어
객체지향적 설계와 유지보수성 측면에서 모두 인상적인 구조였습니다.
특히 동기 호출의 한계를 인식하고, 더 나은 구조를 고민하신 모습에서
서비스 안정성과 미래 확장성까지 함께 고려하고 계신다는 점이 정말 인상 깊었어요! 😊
멋진 구현 감사합니다. 앞으로의 개선 방향도 기대됩니다! ㅎㅎ
| public record CreateUserRequest( | ||
| Long oUserId, | ||
| String name, | ||
| AuthType authType, | ||
| String fcmToken, | ||
| String pushStatus, | ||
| String accountStatus | ||
| ) { | ||
| } |
There was a problem hiding this comment.
운영 서버에서 넘어오는 요청을 담기 위한 CreateUserRequest가 명확한 목적을 가지고 있어서,
서비스 계층에서 도메인으로 전환하는 흐름을 이해하기 쉽게 도와주는 것 같아요!
다만, 문자열로 넘어오는 pushStatus, accountStatus를 enum으로 직접 매핑하는 책임이 DTO 밖으로 노출되어 있어요.
CreateUserRequest 내부에서 of() 같은 메서드를 통해 VO로의 전환을 DTO가 책임지도록 해보면
서비스 레이어의 책임이 더 가벼워지고 객체간 역할 분리가 더 명확해질 수 있을 것 같아요!
There was a problem hiding this comment.
좋은 의견 감사합니다!! 해당 부분을 다음 리팩토링 때 반영해볼께요!!!
⚙️ ISSUE
📄 Work Description
운영서버에서 회원가입 시 회원 정보를 dto에 담아 알림서버의 user에 새롭게 추가하도록 구현했어요!
운영서버에서의 유저 id는 알림서버의 oUserId로써 함께 가지고 있을 수 있도록 구현했어요 :)
그리고 알림서버에서의 특정 컬럼은 회원가입 시 기본값으로 초기화 되도록 했어요.
push_status (푸시알림 설정 여부) >
ENABLEDaccount_status (해당 유저의 로그인 여부) >
ACTIVE그리고 해당 방식이 동기적으로 구현이 이루어지다보니 아무래도 트래픽이 많이 몰리는 상황에서는 비효율적이라는 생각이 들었어요.
이후 구현할때 메시지 큐를 이용해 비동기적으로 처리하는 것을 고려해보면 좋을 것 같아요..!
📷 Screenshot
운영서버에서 회원가입 진행
알림서버의 DB에 해당 정보 정상적으로 저장 (운영서버 userId == 알림서버 oUserId)
✅ PR check list