실제로 실무에서 프로젝트를 진행하다보면 REST API의 여러가지 문제점에 직면할 수 있습니다.
살펴보기에 앞서 GraphQL은 Facebook에서 개발한 GraphQueryLanguage입니다.
REST API는 각각의 API요청에 대하여 EndPoint, 쉽게말해 URL웹주소에 각각에 해당하는 call을 하나하나 만들어주어야 합니다.
실제로 REST API를 호출하면 데이터가 과도하게 들어있는 Over Fetching이나,
데이터가 부족하게 들어있는 Under Fetching 현상을 빈번하게 목격할 수 있습니다.
만약 특정한 서비스를 운영하거나 개발하고 있다고 가정해 보아요.
어떤 회원이 작성한 글이나 팔로워들을 조회하기 위한 서비스를 REST API를 만든다면 어떻게 해야 할까요?
- 먼저 사용자 정보에 대한 요청을 보내서 유저의 key값을 얻어온다.
- 받아온 key를 이용해 해당 유저의 게시글이나, 팔로워를 조회한다.
여기서 필요한 데이터는 사용자의 글이나, 팔로워인데 사용자 정보 전체를 조회하였습니다.
이렇게 실제 필요한 결과물 이외에 좀더 과도하게 데이터를 불러오는 것을 Over Fetching 이라고 합니다.
또한 이러한 비효율적 과정은 매 요청마다 반복되기 때문에 서버에 상당한 무리를 유발할 수 있습니다.
그리고 Facebook에서는 이러한 문제점을 먼저 발견하게 된 것이죠!
또한 팔로워의 정보를 얻기위해 해당하는 사용자의 key를 알고있어야 하는데, REST API를 통해 팔로워 정보를 그냥 요청하게 되면 팔로워에 대한 정보만 나오고 그 팔로워에 대한 정보는 얻을 수 없습니다. 이렇게 데이터가 충분하지 않게 불러와지는 것을 Under Fetching 이라고 합니다.
혹시 기존에 개발을 해보신 분이라면 알겠지만, 버전업을 통해 REST API를 관리하다보면 앞에 v1, v2, v3등 무수히 많은 end point들이 쌓이게 됩니다.
그리고 특정 기능을 수행하기 위해서는 end point를 기능별로 각각 만들어 주어야만 하죠!
이는 작은 프로젝트인 경우에는 문제가 없지만, 중급 이상의 규모로 커지면 프론트앤드개발과 백앤드 개발이 분리가 되어있을 경우 새로운 API를 만들때마다 계속해서 협업요청을 해주어야만 합니다.
물론 모든것을 문서화해서 유지보수 해준다면 괜찮겠지만, 버전관리가 제대로 안되어있을 경우에 기존 버전의 경우에는 시간이 지나면 삭제해주는것이 맞지만 유저들이 인식을 못하고, 문제가 생기는 경우가 빈번하며 이는 회사단위에서 컨트롤 해주기가 매우 까다롭습니다.
바로 위와같은 문제의 패턴들을 효과적으로 해결하기 위해 만들어진 것이 GraphQL 입니다!
모든 데이터가 하나의 그래프 즉 연결되어있고, 필요한 데이터가 있다면 QueryLanguage에 명시되어있는 데이터만 확실히 명시해 주는 것이 특징입니다.
GraphQL의 특징을 정리하자면 다음과 같습니다.
- REST API와는 달리 단일 end point를 가진다.
'/graphql' - 모든 데이터가 Graph로 연결되어 있기 때문에 OverFetching이나 UnderFetching을 근본적으로 해결하였다.
