개발자
관계형 데이터베이스를 사용중인데 총 10개의 칼럼이있는 테이블1과 총 13개의 칼럼이있는 테이블2 를 조인해서 응답해주는 API가 있는데요, 화면에서 필요한 칼럼은 테이블1에서 3개, 테이블2에서 5개 입니다. 이럴 때 테이블2개를 조인해서 카8개를 가진 json으로 리턴해주고 있는데요, 프론트엔드에서 테이블1에 해당하는 타입과, 테이블2에 해당하는 타입을 이미 지정해 놓아서 해당 방식으로 리턴해주면 조인을 하는 API마다 새로운 타입을 정의해야되서 조금 불편한것같다 라는 의견이 있었습니다. 보통 관계형 데이터베이스를 사용해서 조인 후 리턴하는 경우 api는 어떻게 설계하는게 좋을까요?
답변 1
프론트 개발자 분 입장에서는 미리만들어둔 타입의 형태로 내려주면 작업을 덜해도 좋겠지만, 백엔드 API 입장에서는 특정 API는 보여줄것과 안보여줄것을 명확히 구분해야할 의무가 있습니다. 보안측면에서 api단에서 보여줄데이터를 정해서 주면 좋으니까요. 백엔드에서 response Dto는 API마다 분리하는것이 추후 기능 추가요건이 들어오면 수정이 간편해집니다. 뭣하면 다음과 같은 방식은 return을 하면 가능할거 같네요. { "테이블1": {테이블1의 3개만 담겨있는 object}, "테이블2": {테이블2의 5개만 담겨있는 object} } 이렇게 해두면 front 입장에서는 테이블1 key를 가지고 있는 object를 테이블1타입, 테이블2 key를 가지고 있는 object를 테이블2타입 으로 캐스팅해서 사용할순 있지 않을까 싶네요. 그렇지만 front에서도 명확히 타입을 분리해서 쓰라고 하고싶은게, 추후에 테이블1타입으로 받아온 객체중에 없는 데이터를 테이블1타입에 있으니 사용하는 휴먼에러가 있을것 같습니다.
익명
작성자
2024년 03월 20일
의견 감사합니다. 그런데 그렇게 한다고해도 어떤 api에서는 테이블1에서 1,2,3번의 칼럼만 리턴해주고 어떤 api에서는 테이블1의 5,6,7만 리턴해주게되면 결국 테이블1에 해당하는 타입은 모든 키를 nullable하게 만드는 방법밖에 없어서 개발 생산성이 매우 떨어진다고 하더라구요 그 부분을 해결하지 못하고있습니다ㅜ
ㄱㅎㅁ
백엔드 개발자 • 2024년 03월 20일
그래서 api 마다 따로 타입을 만드는게 좋다는거죠. https://tecoble.techcourse.co.kr/post/2020-08-31-dto-vs-entity/ 위 링크는 entity 대신 dto를 사용하자는 의미의 블로그이긴 하지만, 필요한 데이터만을 선별해서 주자라는 내용과 맞습니다. 불필요한 정보를 내려줌으로 인해 쓰레기 데이터가 통신비를 갉아 먹을수 있는케이스도 있겠네요.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!