[FEAT]: payload 조회 Internal API 구현

[twoosky]

Issue number

• resolved 알림 서버에 필요한 Internal API를 생성한다. #134
• resolved Zero Payload 방식으로 이벤트를 재설계한다. #137

작업 사항

• apply, article, group, groupMember payload 조회 internal api 구현
• zero payload 방식으로 이벤트 재설계

[jihwan2da]

수고하셨습니다.
우선 이벤트의 모델 정보를 최소화하여 재사용성을 높이는 부분은 매우 잘하신거 같애요.
근데 현재 다음 코드는 다음과 같은 문제를 정의 할 수 있을 것 같애요

문제 정의

• 현재 Payload가 Event 마다 생성되어 있어서 너무 많은 internal API가 만들어짐.
• 이걸 좀 재활용하는 방향으로 갔으면 좋겠음
  • 예를들어 Apply 이벤트에도 internal에도 그룹이미지가 들어가고 Article, GroupMember에도 image가 들어감. 이걸 이벤트 별로 알맞게 쿼리를 짜야됨.
  • 그럴려면 Event를 다시 설계해야될 것 같음.

위의 문제에 따른 해결책 제안

• Event를 최소화 하기 위해 각 도메인에 맞는 식별자만을 이벤트 모델에 담는 것은 좋은 것 같습니다.
  • 하지만 Apply, Article, GroupMember는 현재 설계 에서는 패키지를 따로 두어 최상위 도메인으로 둔건 맞지만 논리상 Group 도메인에 소속되어 있다고 생각합니다. 어쨋든 Group도메인이 존재하지 않는 이상 위의 도메인들은 무쓸모가되어지는.. 그래서 각 그룹과 관련된 Event마다 groupId, captainId를 담는건 좋다는 생각입니다. 그룹에 관련된 Event에 groupId 및 captainId를 담았을 때 생기는 이점은 아래와 같습니다.

i. 그룹 정보 및 유저 정보에 정보에 대한 internal API를 재사용할 수 있다.

public class UserInternalPayload {
		private Long id;
		private String nickName;
		private String imageurl;
		...
}

public class GroupInternalPayload {
		private Long id;
		private Long captainId:
		private String imageUrl;
		...
}

위의 두개의 InternalPayloadAPI만 사용하여 유저정보 및 그룹정보를 들고 올 수 있습니다.

따라서 Event 마다 각각에게 맞는 InternalPayload API를 생성하는 게 아닌 (이러면 그냥 알림서버용 InternalPayloadAPI가 되는 느낌이라서 재활용성이 떨어짐) 유저정보 및 그룹정보를 들고 올 수 있는 InternalPayloadAPI 두개만 놔둬서 재활용을 한다면 코드의 품질이 더 올라갈 수 있을 거 같습니다.

[twoosky]

@jihwan2da 리뷰 감사합니다 히 😃

저도 각 이벤트의 payload에 중복되는 값이 있어서 payload API를 재사용해보려 했습니다. 하지만, 이렇게 되면 사용하지 않는 값까지 조회해 성능이 낮아질 수 있다고 생각했어요. 예를 들면, apply 이벤트는 groupMember들의 userId가 필요없지만, payload API를 공통으로 사용하는 경우groupMember 테이블과 불필요한 Join이 수행될 수 있을거 같아요. 추가로, 위 방식에서는 user정보와 group의 정보가 모두 필요할 때 API를 2번 호출해야하므로 네트워크 비용이 증가할 거 같습니다. 이러한 이유로 각 이벤트마다 Payload API를 구현했어요.

알림서버용 InternalPayloadAPI가 되는 느낌이라서 재활용성이 떨어짐

이 부분은 Zero Payload 방식의 목적과 맞지 않다고 생각했어요. Zero Payload의 목적은 이벤트를 일반화해 이벤트와 시스템 간 느슨한 결합을 가져가고, 각 시스템마다 필요한 payload를 API를 통해 가져옴으로써 외부 시스템의 Payload 스키마 변경에 유연하게 대처하는 것이라고 생각합니다. 시스템마다 필요한 Payload가 달라질 수 있으므로, 각 시스템마다 다른 Internal Payload API를 사용하는 것이 유지보수에 더 용이하다고 생각해요 :)