[멘토링] DTO의 분리시기, innerClass와 record, 비동기 통신 응답 방법관련 고민(kafka, websoket, gRPC..?)

해당 게시글은 (케인)멘토님께 멘토링 세션을 통해 주고받은 질의응답의 내용을 정리한 글 입니다.

😲 Q1.  멘토님께서는 service DTO controller DTO의 분리시기가 언제라고 보시나요? 

spring boot 어플리케이션에서 dto를 사용 할 때 어플리케이션 개발 초기에는 컨트롤러와 서비스 레이어 각각 나눠서 두기에는 두 dto간 요소 차이가 없을것이고 결국에는 코드의 중복으로 이어지기에, 대부분의 개발 초반에는 하나의 dto로 개발을 진행한 뒤, 프로젝트 규모가 커지면 추후에 분리하는편이라고 들었습니다. 저 또한 토이프로젝트 팀원들과 dto의 레이어별 분리 관련해서 논의를 진행중에 있습니다. 
멘토님께서는 두 레이어에서 dto를 분리해야하는 시기는 언제쯤이라고 보실까요…!

 

👨‍🎓 A1.  각 레이어의 로직이 많이 복잡해지거나 특화로직과 비동기 통신이 들어갈 때 그리고 완전히 다른 entity가 필요하다고 판단이 들때, 팀내의 논의를 통해 분리를 해야한다고 봅니다.

 

😲 Q1-1.  비동기 통신을 적용할 때 dto를 분리해야한다고 하셨는데, 제가 아직 경험이 없어 잘 이해가 가지 않았습니다! 혹시 추가적으로 설명을 해주실 수 있을까요?

👨‍🎓 A1-1. 비동기 통신의 예를 들자면, 의류쇼핑몰 도메인에서 결제 시스템에 토스결제를 도입하는 상황을 예로 들수 있을 것 같습니다.

해당 비동기 통신을 위해서는 첫째로 토스가 원하는 request -dto로 전달하는것이 필요할 것이며, 토스에 요청을 한 뒤 클라이언트에 먼저 응답을 보내주던, ajax로 dto 응답을 보내주던 dto의 종류는 여러개가 될 수 있습니다.
그리고 이런 3자 호출에 대해서도 사용자에게 응답을 내려 줄 때, 해당 요청을 받은 직후 보내는 dto, 3자 호출 request를 보내는 시점의 dto, 3자호출 요청완료후 dto처럼 dto가 여러개가 생기게 됩니다. 보통 현업에서 이러한 3자호출 dto군을 어떻게 이름을 짓고 관리할건지 팀내에서 많은 논의를 하고는 합니다.

 

😲 Q1-2. 비동기 통신 관련해서 설명해주신 내용을 제 현 상황에 적용해서 제가 제대로 이해한건지 말씀드려보면..

이미지 업로드 request(file)를 받았을때 즉시 내려줄 response dto, s3업로드를 시도하기 시작하면서 내려줄 response dto, s3업로드 실패시 재시도를 하면서 내려줄 response dto, s3업로드 완료 후 내려줄 response dto를 각각 분리한다는 관점으로 보면 될까요?

👨‍🎓 A1-2. 그렇습니다. 특히 최근 트랜드로는 해당 응답들을 클라이언트에 내려줄때 요새는 폴링 혹은 웹소켓 경로를 열어놓는 방법이 있습니다.

 

😲 Q1-3. 관련해서 해당 프로젝트의 경우 카프카를 도입할 예정에 있는데, 카프카를 활용해 응답을 보내주는 방법도 검토할 수 있을까요?

👨‍🎓 A1-3. 가능합니다. 혹시 카프카가 무엇이라고 생각하고 계신가요?

 

 

😲 Q1-4. 아직은 이론만 훝어보고 실제로 운영을 해본 경험은 없어 명확히 어떤것이다라고 말하기는 조심스럽지만, 제가 이해한 바로는 메시지 브로커이면서 분산처리를 지원하는 기술이라고 생각합니다.

메시지들을 분산처리함으로써 유실되는 데이터가 없도록 하는데에 사용되어 '반드시 한 번’처리와 여러 설정을 통해 '정확히 한번’까지 지원하는 플랫폼이라고 이해하고 있습니다.

 

👨‍🎓 A1-4. 그렇습니다. 카프카는 범용 메시지브로커입니다. 따라서 위와같은 경우에도 활용 할 수 있습니다. 하지만 보통 클라이언트에서 카프카를 직접 구독하도록 하지 않습니다. 보통은 웹소켓을 열어주거나 grpc나 서버샌드이벤트를 이용하는 편입니다.

 

😲 Q1-5. 마지막으로 dto를 각각의 경우에 맞춰서 만들어주는게 맞다고 본다고 말씀하셔서 생긴 궁금증입니다.

최근 innerClass를 통해 dto를 생성해주는 트렌드도 있던데 멘토님께서는 이러한 방법에 대해서는 어떻게 생각하시나요?

 

👨‍🎓 A1-5. 내부통신용은 innerClass 사용해도 좋다고 봅니다. 하지만 외부통신은 적합하지 않다고 생각합니다.

---

오늘 멘토링과 관련해서 생각/공부해봐야 할 주제 🤔

1. 진행중인 프로젝트 3자 호출 DTO의 명명방법을 어떻게 할 지 고민해보자
2. 클라이언트에서 카프카를 직접 구독하도록 하지 않는 이유는 뭘까?
3. 왜 외부통신에서는 innerClass 방식보다 각각의 dto를 만들어 주는 편이 낫다고 하셨을까?
   • innerClass 사용시 하나의 엔티티에 대한 CRUD용 dto를 하나의 파일과 클래스에서 다룰 수 있다는 점이 좋았는데, 외부 통신의 경우에는 내부 api처럼 CRUD를 하는게 아니라 요청과 응답이 주류라서 응집시키는것보다 명명을 명확하게 하는편이 나아서 그러나?
4. DTO 관련해서 innerClass 방식과 java 14이후의 record 방식을 비교해보는것도 재밌겠다.
   • innerClass 사용시 하나의 엔티티에 대한 CRUD용 dto를 하나의 파일과 클래스에서 다룰 수 있다는 점이 좋았는데, record와 동시에 사용하기에는 어려워 보인다… 그렇다면 응집시킬 dto에 대해서는 innerClas방식을 사용하고, 응집시키지 않을 dto나 복잡한 로직을 가진 dto에 대해서는 record를 사용하는게 좋으려나? 두가지 방법 장단점에 대해서 생각을 정리 해봐야겠다.
5. 클라이언트에 비동기 통신의 응답을 내려줄 방법으로 여러가지 방법이 있는 것 같은데 어떤 방법을 사용할까?
   • websocket 열어주기(채팅 서비스를 위해 적용 예정이기 때문에 좋을것 같기도)
   • gRPC(google Remote Procedure Call)…?
   • Server-Sent Events (SSE)…?
   • Long Polling : 응답을 지연시키기…?
   • 추가 검색 : HTTP/2 Server Push - 클라이언트를 판별할수있는 방법이 뭐지?
     참고 : WebSockets vs SSEs vs gRPC vs Polling vs Webhooks : Efficient Real-Time Communication