[FE] feat: 현재 모든 API에 DTO가 제대로 적용되어 있지 않습니다.

[loopy-lim]

구현 기능

• API에서 DTO를 적용시켜 주세요!
• Response와 Request의 이름을 postfix로 붙이면 좋습니다.!

작업 내용

• API에 DTO를 추가한다.
  • applicant
  • comment
  • interview
  • kanban
  • user
  • work
  • application
  • label
  • score

주의사항

• BE의 문서 스펙에 맞게 수정해주세요!
• 이를 통해 에러가 나오면 이슈를 등록해주세요!

[baegyeong]

1. 클래스 사용해서 적용하면 되나요?
2. interface로 선언되어 있는데 따로 DTO를 적용하는 이유가 궁금합니다.

[loopy-lim]

핵심을 찌르는 질문 중 하나라고 생각합니다.

1. 클래스로 적용하는 것이 편할 것이라고 생각합니다.(다른 방법은... 수정하기가 귀찮을 것이라고 판단합니다)
2. 따로 DTO(ViewModel)을 적용하는 이유는, 추후 백엔드에서 데이터가 변할 때 전체적인 코드가 변하는 것이 아니라 DTO만 변하면 된다 라는 장점을 이용하고 싶기 때문입니다.

[baegyeong]

아! 그렇군요
그럼 api 파일 안에서 각각 dto를 추가...하기보다는 src 파일 안에 dto 폴더를 추가할까요?

[2yunseong]

아주 좋은 질문입니다 배경님

채승님이 설명하신 2의 예시를 들어보겠습니다
아주 간단한 예시로 백엔드의 API가 다음과 같았습니다

 interface GetUserResponse {
  id: number;
  name: string;
  favorites: string[];
}

그런데 favorites가 likes로 변할 때, DTO를 적용하지 않는다면 컴포넌트 코드 단까지 모두 변경해주어야 합니다.
(이 부분은 상상해보시기 바랍니다)
하지만 우리는 DTO를 둠으로써 DTO constructor의 parameter만 바꿔주면 손쉽게 바꿔줄 수 있죠!

interface GetUserResponse {
   id: number;
  name: string;
  likes: string[];
}

export class User {
  id: number;
  name: string;
  favorites: string[];
  constructor({ id, name, likes }:GetUserResponse) {
    this.id = id;
    this.name = name;
    this.favorites = likes // 이 부분만 변경
  }

그렇담 DTO를 둠으로써 단점은 무엇일까요 ?

[baegyeong]

간단하게 interface를 선언하는 것보다 매 객체마다 dto를 적용한다면 코드의 복잡성이 더 증가하지 않을까..생각 합니다.!