데이터 가공이란
앞서 필자는 주니어 프론트엔드 개발자이며 필자가 생각하는 데이터 가공에 대해 적어보려 한다.
적은 경험으로 인한 짧은 생각일 수 있으므로 반박 시 님 말이 다 맞음.
웹 혹은 앱 개발을 할 때 우리는 DB에 있는 데이터를 가져와 사용하게 된다.
이러한 문자형, 숫자형, 날짜형과 같이 DB는 데이터의 타입을 정하도록 되어 있다.
🙋♂️: 객체나 배열은 없나요 ?
DB를 만져보지 못한 프론트엔드 개발자들도 있기에 이러한 질문을 할 수 있는데 배열이나 객체는 없다.
하지만 OpneAPI나 사내에서 API를 호출하여 받게 되면 대부분 배열 혹은 객체 형태로 잘 나오게 된다.
/** 메이플 스토리 API */
{
"count": 0,
"next_cursor": "string",
"starforce_history": [
{
"id": "string",
"item_upgrade_result": "string",
"before_starforce_count": 0,
"after_starforce_count": 0,
"starcatch_result": "string",
"superior_item_flag": "string",
"destroy_defence": "string",
"chance_time": "string",
"event_field_flag": "string",
"upgrade_item": "string",
"protect_shield": "string",
"bonus_stat_upgrade": "string",
"character_name": "string",
"world_name": "string",
"target_item": "string",
"date_create": "2023-12-27T17:28+09:00",
"starforce_event_list": [
{
"success_rate": "string",
"cost_discount_rate": "string",
"plus_value": "string",
"starforce_event_range": "string"
}
]
}
]
}위의 API는 메이플 스토리 API 중 스타포스 관련 API의 response 값의 형태이다.
분명 DB에서는 객체와 배열을 담아둘 수 없다고 했는데 어떻게 저렇게 API를 보내줄 수 있는것인가.
대장장이 백엔드
바로 백엔드 개발자 분들이 데이터 가공을 해주어 던져주기 때문이다.
때문에 페이지 개발을 하기 앞서 API 설계를 하게 되는데 이때 프론트에서 어떠한 형태의 response 값을 받을지 이야기해주면 된다.
예를 들어 유튜브 메인화면 중 숏츠의 일부분을 어떠한 형태의 response로 받을 지 알아보자
우리가 필요한 데이터는 이미지와 hover시 실행 될 수 있는 동영상, 제목과 조회 수 정도가 있을거 같다.
[
{
img: "암살이미지.png",
preview: "암살 영상",
title: "언니가 해결할게 #암살",
view: 10237,
},
{
img: "제시이미지.png",
preview: "제시 영상",
title: "똥고집 싸이가 변화시킨 가수들",
view: 7843107,
},
{
img: "SNL이미지.png",
preview: "SNL 영상",
title: "나랑 짜장면 먹으러 갈래 #snl코리아 #시즌4",
view: 910782,
}
]
대충 이러한 형태로 받아오게 되면 프론트에선 해당 데이터들로 화면에 뿌려줄 수 있게 되는 것이다.
여기까지가 내가 백엔드 개발자들에게 바라는 데이터 가공이다.
프론트엔드 넌 뭐하는데
🤔: 아니 백엔드에서 다 해주는데 프론트에서 무슨 가공이 필요하다는건가요.
맞다. 백엔드에서 대략 90%의 가공을 해주기 때문에 프론트에서는 그렇게 큰 가공이 필요가 없다.
하지만
위의 데이터를 그대로 뿌려줄 수는 없다. 바로 "view" 때문이다.
유튜브에서는 조회수가 1천 미만일 때는 1의자리 숫자까지, 1만 미만일 때는 소수점 1의 자리에 백단위 숫자까지, 10만 이하 일 때는 소수점 1의 자리에 천단위 숫자까지 표시해준다.
이러한 로직은 프론트에서 짜야하며 렌더링 해주어야한다.
이외에도 날짜를 YYYY-MM-DD의 형태로 보여줄 것인지. YYYY.MM.DD의 형태로 보여줄 것인지. 와 같이 프론트에서 유연하게 사용할 수 있도록 데이터를 가공해야 한다고 필자는 생각한다.
꿀밤 마려운 상황
백엔드 개발자가 프론트 개발자에게 꿀밤을 때려주고 싶은 상황이 있을 것이다.
👽: 평균 값이 54.3이라는 숫자로 들어오는데 %까지 붙여서 주시면 안되나요 ?
👽: 날짜 데이터를 YYYY-MM-DD로 보내주셨는데 기획자 분이 DD-MM-YYYY로 바꿔달래요.
👽: 유튜브 조회 수에 따른 "XX.X만 회"와 같은 형태로 보내주실 수 없어요 ?
프론트 개발자는 항상 근거를 가지고 백엔드 개발자에게 부탁을 하자.
😺: 이 데이터는 백엔드에서 작업을 해주시면 제 쪽에서 불필요한 mapping이 줄어들거 같아요 !
😺: 000은 백엔드에서 데이터 검증을 완료해주시고 보내주시면 좋을거 같아요 !
이러한 상황이 있을 수 있다.
상황1
const data = [
{
c1: 'foo',
c2: 'bar',
_children: [
{
c1: 'baz',
c2: 'qux'
},
// ...,
]
},
// ...,
];Toast UI Grid라는 라이브러리 중 Tree 구조의 그리드이다.
해당 그리드는 위의 코드와 같이 children이라는 배열로 들어가야 부모 데이터 하위로 자식 데이터가 들어가게 된다.
/* response */
const response = [
[{id: 1, c1: "foo", c2: "bar"}],
[{id: 13, c1: "baz", c2: "qux", upperRowId: 1}],\
// ...,
]위의 예시는 단편적으로 데이터가 2개 뿐이며 깊이도 깊지 않은 데이터이지만 깊이가 깊고 데이터가 많다면 백엔드 개발자에게 맛있는 사탕과 함께 데이터 가공을 의뢰해볼만하다.
상황2
Grid(Table)을 뿌려줄 때 UniqueKey 필요한 상황인데 데이터에 UniqueKey를 사용할만한 데이터가 없다고 가정해보자.
만약 백엔드 개발자가 이 데이터를 가공할 때 반복문을 사용하는 로직이 있다면 해당 부분에 id 값을 넣어달라고 의뢰해볼만하다.
(만약 반복문을 사용하는 로직이 없다면 프론트에서 그냥 id 값 넣어줘도 나쁘지 않을거 같다.)
착한 백엔드분들이라면 프론트의 아쉬운 발걸음에서 id값 넣어주신다.
마무리.
1년차 주니어 개발자이기 때문에 위의 예시에 대해 의문을 가지실 분들도 계실 수 있다.
반박 시 님들 말이 다 맞다
요즘들어 MSA와 더불어 BFF(BackEnd for FrontEnd)라는 패턴도 나오는 것으로 보아 확실히 백엔드 개발자 분들이
프론트 개발자를 위해 열심히 노력해주시는 것 같았다.
API 설계를 할 때, 백엔드 개발자와 소통할 때 도움이 되셨으면 좋겠습니다.
감사합니다.🥰
