Portfolio

❓ 비동기 질문과 답변 모음

질문

예전부터 질문해왔던 서비스가 서비스를 의존하는 것에 대한 질문입니다!! 만약 예약 도메인쪽에서 User에 대한 객체가 필요할 때 서비스를 통해 받아오게 된다면 User 자체를 넘겨주는 메서드를 구현해야할 것 같은 데 UserService에 User를 넘겨주는 UserProvider라는 인터페이스를 구현하여 넘겨주는 것이 더 좋을 까요?

User 객체로 연관관계를 잡는 것이 아닌 userId로만 연관관계를 잡는다고 하면 UserService에게 존재하는 지에 대한 메시지만 보내도 충분할까요?

프로젝트를 시작할때 기능 명세를 쭉 뽑고 객체를 먼저 설계한 후 디비를 설계하시나요? 아니면 반대로 하시나요?

프론트와의 협업을 위해 더미데이터를 넘겨주는 컨트롤러단을 먼저 구현한 뒤 이후 서비스나 도메인을 구현하고 싶은데 이런 식으로도 협업을 진행하나요??

답변

UserService에서 직접 User를 넘겨줘도 될 것같은데.. UserProvider엔 어떤게 들어가게 되는거죠?

UserProvier는 User 객체 자체를 넘겨주고 UserService는 Dto만 넘겨주는 식으로 될 것 같습니다. 그냥 UserService가 다 책임지고 controller에서 entity -> dto로 변환하는 것이 맞을까요?
좀 더 객체를 쪼갠다면 그렇게 해도 될것 같긴한데.. 저는 controller에서 entity-> dto 변환도 괜찮다고 생각합니다.

넵넵, userId만 필요하면 userId가 유효한지 여부만 체크해도 될것 같아요!

기능명세를 만든 후, 디비를 설계하고, 그걸 바탕으로 객체를 만드는데 어떻게 보면 둘이 거의 동시에 이뤄지는 작업인 것 같아요! 그래서 어떤걸 먼저해도 상관없을것 같습니다.

api spec을 미리 정해서 넘겨주고, 그걸로 프론트에서 모킹을 할 수 있도록 하기도 하고, 만약 실 api를 원하면 controller를 먼저 구현할 수 도 있을것 같아요. 보통은 api가 전체 완성되고 프론트에게 제공해주는데 controller를 먼저 제공해주는 것도 하나의 방식인것 같습니다.

추가적으로 MSA에서 User에 대한 정보가 필요하면 API로 통신하는 것으로 아는 데 이때 받는 값은 User 객체 자체인가요 아니면 Dto인가요??

1. MSA로 변환시 하나의 api이기 때문에 (물론 내부적으로 사용할 api를 따로 만들수도 있지만) 언제 어디서 호출될지 모르기 때문에 User객체보다는 Dto로 넘겨줍니다!

질문

이번 프로젝트때 스웨거를 한번 도입해보려고 하고 있는 데 스웨거 어노테이션을 많이 붙이면 자세히설명해줄 수 있긴 하지만 너무 프로덕션 코드가 더러워진다? 라는 단점이 있는데 멘토님이 사용하실 땐 어느정도 선까지 사용하시나요?

답변

저는 사실 그렇게 자세하게 적진 않습니다.

필요에 따라 커뮤니케이션으로 가능한 부분이 있어서..

어떤 용도인지 정도만 적어줍니다

질문

멘토님의 경우 Service단 테스트는 Mock으로 처리하시나요?? 저희가 일단 정한 건 @SpringBootTest를 통해 서비스레이어는 통합으로 가져가기로 했습니다

답변

보통 모킹을 하지만 테스트 간소화를 위해서 SpringBootTest를 사용하는것도 나쁘지 않다고 생각합니다~ 간소화라기 보다는.. 핵심만 테스트하자?

질문

안녕하세요 멘토님 질문있습니다!!

현재 다음과 같은 페이지에서 회원 프로필 수정을 진행하고 있는 데 회원 프로필에서 커플 정보도 수정을 받는 데 두 개의 도메인 개념이 달라 API를 두 개를 사용해야할지 하나로 사용해야 할지 고민이 됩니다.

현재는 회원 프로필(/api/members) 수정과 커플 프로필(/api/couples) 수정 두 개를 사용하는 것으로 결정하였는데 맞는 방향일까요?

답변

넵 두개로 사용하는게 더 좋을것 같네요. 대신 커플 프로필 수정은 커플 관련 정보만 수정하게 하고, 회원 프로필은 회원 정보만 수정하도록 하는게 좋을것 같네요

질문

그럼 다음과 같이 왼쪽이 솔로일 경우 오른쪽이 커플일 경우 프로필인데 마찬가지로 왼쪽은 /api/members로만 접근하고 오른쪽은 api/membersapi/couples 두개로 접근하는 것이 맞을까요?

답변

음.. 넵 불편하지만 그렇게 하는게 나을것 같네요!

질문

멘토님! 추가질문입니다!!

현재 태그의 경우 커플들만의 태그가 필요해서 ERD 상에 커플 ID를 가지도록 만들었습니다. 이것보단 커플태그 테이블을 하나 더 만들어서 그쪽에서 매핑해주는 것이 더 좋을까요??

답변

거기엔 커플Id, 태그Id만 들어가나요?

넵넵 굳이 테이블을 하나 더 만들어야 하나 싶네요

👨🏻‍💻 안녕하세요 멘토님! 질문있습니다.알림 서버를 따로 띄울 필요가 있다고 말씀하셨는데 그럼 이러한 인프라로 돌아가는 구조일까요??

클라이언트는 로그인을 하고 jwt토큰을 받는다.

받은 jwt토큰을 가지고 알림 서버에 구독 요청을 한다.

메인 서버에서 이벤트가 발생하면 FCM이나 Redis에 메시지를 전달한다.

전달받은 메시지를 알림 서버에 전달한다.

알림서버는 구독한 사용자에게 해당 메시지를 전달한다.

👨‍🏫 넵 저런식으로 하면 될거 같은데 굳이 인스턴스를 안 띄우고 메인 서버에서 알림서버 같이 해도 뭐 큰문제는 없을것 같기도 해요

👨🏻‍💻 메인 서버에서만 한다면 레디스나 FCM의 pub/sub를 사용하지 않고 저장, 삭제로만 구현하게 되는 걸까요?

👨‍🏫 그렇게 되겠죠? 굳이 pub/sub을 이용할 필요가 없을테니까요

근데 저런 아키텍처를 설계 해보는데 의의를 가진다면 알림서비스 분리해도 좋습니다

👨🏻‍💻 분리한다고 했을 때 최종 아키텍처는 이런 모습으로 가는 걸까요??

추가적으로 레디스의 pub/sub는 따로 이벤트를 저장하지 않기 때문에 구독시에만 알림을 받을 수 있을 것 같습니다. 이런 경우 알림 서버 EC2에 rds나 redis를 하나 두어서 로그인시 못보낸 이벤트들을 다시 보내주는 것이 맞는 걸까요?

👨‍🏫 넵넵 분리하면 저런식으로 되는거겟죠?

보통 저렇게 발송에 실패한 애들을 따로 처리하는건 데드레터큐라는 아키텍처 패턴으로 전송 실패한 애들을 따로 모아서 처리합니다.

근데 그렇게 아키텍처를 가져가기엔 너무 복잡할거 같고.. 그냥 알림자체는 무시하되 알림 기록정도만 남겨둬서 나중에 사용자가 저런 알림이 있었다는 확인정도만 하도록 하면 될것 같네요

👨🏻‍💻지난 알림 확인같은 API를 하나 만들어야 겠군여.

일단 메모리 상으로 돌아가게 만들고 후에 디비상으로 돌아가게 만들어 봐야겠습니다.

CI,CD랑 nginx 부터 만져야 겠네요

👨‍🏫 네네 유저별로 알림기록 쌓는 테이블 두고 그거 조회하게 하면 될거겉어요

👨🏻‍💻 이벤트가 들어오면 실시간으로 내려주는 것이 아닌 모든 것을 API로 하는건가요?

아니면 구독중이라면 SSE나 소켓으로 실시간으로? 내려주는 걸 말씀하시는 건가요?

👨‍🏫 알림을 가능하게 하는 모든 이벤트들이 일단 테이블에 쌓여야하긴 할거 같네요.

그리고 구독중이지 않아서 못내려주는 애들을 어쩔수 없이 알림을 못보내지만 추후에 확인할 수는 있게 만드는거죠

👨🏻‍💻안녕하세요 멘토님 질문이 있습니다. 만약 알림서버를 분리한다고 했을때 멀티모듈을 적용하면 서버를 분리한 것과 같은 개념일까요??

👨‍🏫 넵 정확히 서버 분리는 아니지만 비슷한 효과를 줄순 있겠죠?어차피 하나의 인스턴스만 사용할거면 멀티모듈로 해도 될거같아요

😠 훈수 미팅

1기 선배님들 초대 : 함승훈님, 한재원님

최종 플젝 이후 느낀점

의도는 좋지만 자신의 역량을 쥐어짜낼 수 있는 주제가 되었으면 좋겠다.

DevNity를 하면서 돌아보니 기술적으로 아쉬웠던 거 같다.

기능은 많이 만들려고 했지만 CRUD 뿐이 없었다.

기능은 적더라도 딥하게 들어갈 수 있도록 했으면 좋았겠다.

지금 취준하면서 인프라는 어느정도만하고 하나의 기능을 짜더라도 고민을 해라. 조회를 할때도 캐시에 대한 부분에서 고민하는 등에서~

사용했다가 중요한게 아니고 이것을 사용하면서 어떤 생각을 가지고 사용한 것인가?

사용해보려고 하면 이 기술에 대해서 알고 사용해야한다.

프로젝트때 이건 챙겼으면 하는 것

CI/CD

무중단 배포

부하 테스트

코드 리뷰

웹 서버, 캐시

API 문서 자동화

기술 선택하는 과정에서 고민을 해봤냐??

일관적인 코드를 짜라 ( 5명이 짜도 1사람이 짠 것처럼 )

비즈니스쪽으로 정책이 있는 것이 좋다.

신고 기능
조회수 어뷰징

외부에서 for문으로 요청을 보낸다면 어떻게 막을것인가?

이미지 저장

해주고 싶은 말

자소서에 쓴 내용은 다 알아야 한다.

나의 프로젝트는 다 알아야 한다.

자신감을 가져라

모르겠으면 당당히 말해라

현실과 타협할 줄 알아야 한다.

조금 준비가 되었다고 생각하면 면접을 봐라

매일 스터디 최대한 자주

이론 돌리기
주제 선정 → 공유 → 피드백
정하고 만나서 질문

자신감을 가져라

🚀 주제 관련 미팅

지금 기능은 거의 CRUD 복붙과 같은 느낌이다.

기술게시판과 질문게시판 동일하다.

하나의 게시판을 조금 더 딥하게 가져가는 게 좋을 것 같다.

지도 써보는 것도 좋다.

간단한 채팅은 아니더라도 쪽지 기능

단방향 전송
채팅과 쪽지의 창

서로 주고 받을 수 있도록 하던가?
비동기적 쪽지로 보낸다

API 해결할 수 있다.

모집 게시판을 가져갈 거면 복잡도를 올려서 처리해보도록 한다.

신청을 한다
주최자가 수락 및 거절한다.
신청자가 수락 및 거절에 대한 쪽지를 보낸다.
혹은 거절 및 수락에 대한 알람을 보내도록 한다.

하나의 서비스를 가지고 깊게 파고 들어가라~

신고하기

신고에 당한 자는 그 안의 정책을 가져갔으면 좋겠다

ex) 신고당한 자는 한달동안 신청할 수 없다.

블랙리스트 등록

스터디를 하면서 했던 것들을 기술블로그로 확장할 수 있도록?

벌금 정책

강퇴 기능

쫒겨난 사람은 스터디 지원 및 개설을 못하도록 한다.

쪽지, 모집, 지도

회의록 생성, 주차별 회의 출석 비율

출석 조회

내부게시판 같은 기능

스터디 내에서 해봐라

총 정리

게시판 갯수를 처리한다

기술 블로그 하나만 남도록 한다.

조회수
좋아요

모집 서비스에 대한 기능을 강화한다

게시판이 아닌 신청으로 수락 및 거절할 수 있도록한다.
수락 및 거절에 대한 알람/쪽지가 가도록 한다.
출석, 출석 조회

지도

스터디 장소

정책까지도 정하면 좋을듯

스트레스 테스트 하면 좋다.

팀02 백엔드 코칭 일지