[항해99] DTO & Over-Fetching

프론트와 만나는 미니 프로젝트 주간이다.

프론트와 연결해본 적이 한 번도 없어서 어떻게 해야할지 걱정이 많았다.

일단 통신하는 게 난관이다.

리액트가 데이터 보내는 거 전혀 모른다구...

나중에 이 부분도 공부해보면 좋지 않을까..? ㅎㅎ....ㅎ.ㅎ..ㅎ.ㅎ..

 

그런데 막상 구현 기능을 줄이고 연결하는 부분에 집중하자고 하고 나니 긴장감이 와르르 무너졌다.

느슨한 마음이 들어서인지 코드를 짤 때 기능이 돌아가게만 하는 데 그치는 것이 아니라 구조까지 눈에 들어오게 됐다.

그래서 DTO와 관련해서 공부해보기로 한다.

 

지난 주차 때 과제를 하면서 DTO에 대해 상당히 잘못 알고 있었다는 사실을 알았다.

변수가 entity와 일치해야 하는 줄 알고 있었다.

DTO의 존재 의의는 데이터를 들고 다니는 역할이고...entity를 직접 들고 다니지 않으면서 가공하기 위한 거라고.......

하하!!! 이렇게 되면 정말 아무런 의미가 없지 않나!!!

DTO는 entity와 별개로, 요청 받고 / 응답할 때 사용하는 보자기 같은 거다.

entity에 5개의 데이터가 있는데 id, name만 넘어온다면 id, name만 들어있는 DTO를 만드는 거다.

DTO를 만드는 이유는 @RequestBody로 JSON 형태로 받으면 객체 타입으로 변환해주므로, 박스 째 들고다니기 편하라고 그런 것 같다.

응답하는 경우도 마찬가지다.

약간의 서치를 하니 정말 그랬다.

내 마음 한구석에서 DTO는 쓰잘데기 없는 것이란 생각이 있었는데 내가 멍청했던 거다.

 

그런데, 이렇게 DTO를 만들다보니 DTO 폴더가 상당히 지저분해졌다.

update 관련 DTO만 3개나 나와버린 것이다.

- TodoUpdateDto, TodoUpdateCompleteDto, TodoUpdateResponseDto

네이밍도 길고..가독성 떨어져..

 

그리고 새로운 문제가 있었다.

응답 시, 클라이언트에서 데이터를 잘 가공해서 쓰는 게 좋겠거니 해서 전체 엔티티를 다 내려줬는데, 이건 안 될 일이었다.

Over-Fatching이라는 개념이 있는데, 쓰지 않는 데이터를 과하게 내려줌으로써 네트워크 지연이 발생한다고 한다.

아니 근데 고작 텍스트 데이터 보내는데 지연이 생긴다고..? 싶긴한데, 안 쓰는 거 사이에서 데이터를 찾아야 하는 수고로움이 있을 것 같긴하다. 거기다 아무나 다른 데이터를 조회할 수 있으니 위험해 보이기도 한다.

 

ResponseDto는 불필요해지므로 삭제하기로 한다. 

그럼 나머지 두 개의 DTO가 남는데, 다른 클래스와 합쳐지면 환장 파티가 벌어질 것 같다.

인터넷에 찾아보니 내부 클래스를 만드는 방법이 있었다.

오 좋은 방법인 것 같아 적용을 했는데, 그건 아래와 같다.

public class UpdateDto {

    @NoArgsConstructor
    @Getter
    @Setter
    public static class TodoUpdate {
        private long id;
        private String todo;

        @Builder
        public TodoUpdate(long id, String todo) {
            this.id = id;
            this.todo = todo;
        }
    }

    @NoArgsConstructor
    @Getter
    @Setter
    public static class CompletionUpdate {
        private long id;
        private boolean checkComplete;

        @Builder
        public CompletionUpdate(long id, boolean checkComplete) {
            this.id = id;
            this.checkComplete = checkComplete;
        }
    }

}

 

Controller에서는 아래와 같이 호출한다.

네이밍도 같이 정리했다.

과연 의미가 잘 전달되는지? 네이밍 기법도 궁금해진다.

@PutMapping("/todo/{goalDay}/{id}")
public UpdateDto.CompletionUpdate updateComplete
(@PathVariable Long id, @RequestBody UpdateDto.CompletionUpdate completetionUpdate) {
    completetionUpdate.setId(id);
    return todoService.updateComplete(completetionUpdate);
}

 

 

* Over-Fatching의 반대말로, 데이터를 적게 줘서 api를 여러 번 호출해야 하는 Under-Fatching이라는 개념도 있는데 이를 해결하기 위해 GraphQL이 있다고 한다. 이건 따로 공부해보자.