1.
UnderFetching
2.
OverFetching
1. UnderFetching
Under Fetching은, 백엔드 개발자가 좀 더 데이터를 세분화해서 저장하기 위해서 REST API의 Request URL을 여러 개로 쪼개놨을 경우에 발생할 수 있습니다. 유저 정보들로부터 특정 유저의 정보까지도 얻고자 할때,
{
"persons": [
"1": {
"name": "이시영",
"location": 1,
"age": 20
},
"2": {
"name": "김민주",
"location": 5,
"age": 20
}
]
}
JSON
복사
이라는 데이터가 넘어온다고 생각해보겠습니다. 여기서 우리가 집 주소까지도 알고 싶은데, 백에서 좀 더 세분화해서
{
"1": "서울특별시",
"2": "인천광역시",
...,
"5": "대구광역시"
}
JSON
복사
로 설정해뒀다고 생각해보시면, 우리는 persons(배열을 넘겨주는) url을 한 번 호출해주고, location key값의 숫자값을 통해서 다시 location정보의 url을 한 번 호출해줘서 찾아야합니다. 이런 두 번의 귀찮은 과정을, GraphQL은 한 번의 호출로 해결할 수 있도록 도와줍니다. 위의 일련의 과정, 정보를 덜 받는 바람에 굳이 몇 번 더 호출해야할때를 under-fetching이라고 하는겁니다.
2. OverFetching
우리가 현재 상영중인 영화 정보를 보여주는 사이드 프로젝트를 진행한다고 떠올려보면,
우리가 필요하지 않는 데이터마저 전부 넘어온다는 것을 알 수 있습니다(제작일, 관객수 같이 활용하지 않을 정보들). 우리가 영화 각각의 정보에서, 제목+포스터 이미지만 필요하다면, REST API는 GET요청을 보내면 모든 정보를 어쩔 수 없이 다 가져오는 반면에 GraphQL은 제목과 포스터 이미지만 보내주는거죠.
굳이라고 생각할 수도 있지만, 데이터가 만약 몇 천 만개라고 생각하면, 딜레이가 안 생길 수가 없습니다.
다음과 같이 생각해보겠습니다.
# GET /api/movie/3
{
id: 3,
name: '신세계',
star: 4.5,
posterUrl: 'http://....',
year: '2020년 1월 1일',
...
등등 대략 100개의 정보가 더 존재
...
}
JSON
복사
이럴 경우에, 프론트엔드 개발자가 UI 표현을 위해서는 영화 이름, 포스터 이미지 주소만 필요로 한다고 하겠습니다. 나머지 정보들은 필요하지 않음에도 어찌됐든 요청에 의해 함께 넘어오게 됩니다. 함께 있는 정보들의 개수가 적다면 굳이 필요하지 않겠지만, 만약 JSON의 key 개수가 1000개라면? 엄청난 낭비라고 본다는 거죠.

