물론 API 스펙에 따라 쉽게 변경될 수 있고, 그러기 위해서 Dto 를 마련해 놓는 것이다. 하지만 응답마다, 요청마다를 위해 Dto 를 마련하는 것은 조금 비효율 적인 것 같다는 생각이 들었다. (이게 맞는 생각인지는 잘 모르겠음)
예를 들어보자.
현재 모임을 생성하고 생성 완료에 대한 응답을 보내주려 한다.
1) 생성 완료했으니 아마 플로우가 그 모임 화면으로 이동하는 것일 것. 그거에 맞춰서 바로 모임 화면을 뿌려줄 수 있도록 바로 생성된 모임 정보를 전송해준다.
2) 생성 완료했으니 생성된 모임에 대한 PK 값 정도만 응답해줌. 그리고 플로우가 어쨌든 생성된 모임으로 이동해주기 위해서는 다시 한번 모임 PK 에 대한, 그리고 현재 유저에 대한 요청을 다시한번 진행해야 한다.
> 1과 같은 경우 요청을 줄일 수 있다는 큰 장점이 있다. 요청을 최소화 하는 것은 쿼리를 최소화하는데 매우 중요하기 때문이다. 하지만, 만약 화면 플로우가 바뀐다면? 그리고 만약 또다른 API 가 생겨서 다른 방식으로 모임을 생성해줘야 한다면? 그 때마다 새로운 응답 형식을 마련해줘야 할 것이다. (화면 플로우 의존성이 조금 있음)
> 2와 같은 경우 일관된 API 를 제공해줄 수 있다. 하지만, 요청 수가 늘어나게 된다.
어떻게 보면 1이 맞는 것 같기도하지만, 쿼리 하나라도 줄이기 위해 ㅈ빠지게 쿼리를 짜는 백엔드 개발자들인데 이런 부분에선 관용적으로 응 요청 수 늘려도 돼 하는 상황이 모순되기도 한다.
누구한테 물어보든, API Spec 은 쉽게 변경 가능하니까, 편하게 짜면 된다고 함. 그리고 1,2 다 맞는 방법, 크게 고민할 거리가 아니라고 함.
글쎄 난 그렇게 생각이 되지를 않는다. API Spec 이 어떻든 최대한 interface 처럼 해결해줄 수 있다면, 그건 정말 좋은 interface 일 것이다. 어떤 API Spec 이 오든, 구현체에서 변경해주면 되기 때문이다. 그리고 2번도 말했듯이 쿼리 하나하나에 예민한 백엔드 개발자가 쉽게 그렇지 하면서 2번을 선택하면 안된다고 생각한다.
결론은 이것이였다.
- 응답을 위한 "응답 도메인 Interface" 처럼 설계하고, 필요한 부분들을 선택하여 응답을 제공해주면 되지 않을까? 그래서 Interface 는 어떨까에 대해서도 생각을 해봤다.
Interface 는 "역할"을 담은 객체이다. 프로그램 내에서 그 역할을 수행하기 위한 껍질면이 존재하는 것이였다. 그 역할을 설명하기 위해서 가장 대충 설명할 수 있는 것. 하지만 지금 응답을 위해 그렇게 설정할 수가 있을까? 응답은 역할을 수행하기 위한 함수들이 내재되어 있다기 보단, 응답을 하기위한 모델들이 들어가 있다. 그리고 이미 ResponseModel 객체가 많이들 Generic 하게 존재할 것이고, 그 Generic 에 응답하는 Model 을 보통 담아서 이미 꽤 탄력적인 모델링이 되어 있다고 볼 수 있다.
> 그래서 Interface 만이 이걸 위한 좋은 방법은 아닌 것 같다고 생각을 했다. 응답하고 있는 도메인 모델들이 수행하는 역할이 다르기도 하고, Response Model 로 이미 충분히 [응답] 을 위한 공통 분모는 묶어놓은 셈이기 때문이다.
> 그래서 위에서처럼 이번 도메인을 위한 추상적인 Dto 를 만들어보기로 했다.
> 예를 들면, 다음과 같이 생각해보자.
@Data
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class MoimResponseDto {
private MoimDto moimDto;
private List<CategoryDto> categoryDtos;
private RuleJoinDto ruleJoinDto;
private RulePersistDto rulePersistDto;
private MoimMembersDto moimMembersDto;
}
해당 응답을 위한 Dto 들이 조립되어 응답을 만드는 형식으로 만들어 본 것이다. 내부에 있는 MoimDto, RuleDto 들은 상황에 따라 다른 응답을 위해서 쓰일 수도 있는 Domain Dto 들로 볼 수 있고, 만약 해당 모임에 대해서 미리보기 정도만 하는 상황이라면 MoimDto, CategoryDto 정도만 조립해서 응답해줄 수 있는 것이다.
따라서, 위 1, 2의 단점들을 모두 해결할 수 있다고 생각을 했고, 이렇게 설계해보도록 하겠다.