GraphQL 이란?

REST API와 더불어 웹 상에서 가장 많이 사용되는 클라이언트-서버간의 통신을 담당하는 API를 위한 쿼리언어이다. REST API의 단점을 개선할 목적으로 facebook에서 만들었고, 필요한 데이터만 명확하게 가져온다는 점에서, 개발자들에게 긍정적인 평가를 받고 있다.

REST API의 단점

• Over-fetching : REST API의 응답의 형태는 고정적이다. 예를들어 사용자의 닉네임을 알기 위해서 사용자를 조회하는 요청을 보내는 경우, 닉네임외에도 이름, 나이, 아이디 등이 함께 올 수 있다. 그렇다하여 하나만 반환하는 요청들을 일일히 만들어주는 것도 시간 비용 대비 좋지 않다.

• Under-fetching : Over-fetching의 반대 개념으로, 응답의 형태가 고정되어 있기 때문에 여러 요청을 보내야만 하는 경우이다. 예를들어 사용자의 닉네임과 그가 좋아하는 영화리스트 데이터가 필요한데 현재 DB 스키마가 User, Likes 로 나뉘어진 경우 클라이언트는 User 관련 요청과 Likes 관련 요청을 각각 진행해주어야 한다.

특징

단일 엔드 포인트

graphQL은 기존의 클라이언트-서버가 통신을 진행한던 작업 사이에 service broker를 들어가 서버와 클라이언트를 중개한다. 즉 클라이언트에서 데이터를 조합하는 역할이나, 서버에서 진행했던 반복적인 API 작업들을 graphQL이 대신 처리한다. 따라서 기존에 클라이언트는 서버에게 요청 시 필요한 URI를 더이상 알지 않아도 되며, 서버는 매번 URI를 만들지 않아도 된다.

유연성

클라이언트는 필요한 데이터만 요청하면, 서버는 클라이언트가 필요로 하는 만큼의 데이터를 반환한다. 서버로 부터 받는 데이터의 사이즈는 REST API 대비 줄어들게 되며, Over-fetching 및 Under-fetching 문제를 해결하였다. 이러한 기능 덕분에, 일반적으로 REST API 대비 성능적인 면에서 좋다고 한다.

단점

캐싱

단일 엔드 포인트와 동적 리소스 생성에 의한 단점으로, REST API의 경우 엔드 포인트가 여러가지 이며 리소스 에 대한 요청-응답이 고정적이기 때문에, 효율적인 운영환경을 위해 캐싱 기능을 함께 사용하는 것이 좋다. 그러나 GraphQL은 요청과 응답이 동적으로 변환할 수 있기 캐싱의 의미가 사라진다

구현

클라이언트, 서버 모두 graphQL 통신을 위한 모듈 설정이 필요하다. 기존 SQL 외의 graphQL에 대한 이론지식이 필요하며, 커뮤니티의 경우 REST API 대비 그렇게 크지 않기 때문에 사례를 찾는 것이 어려울 수 있다.

기타

모든 요청에 대해 query를 함께 보내야 한다는 점에서, 특별한 매개변수가 필요하지 않은 조회 요청의 경우, REST API 대비 요청 크기가 클 수 있다.

참고
이 영상을 보고나면 REST API 를 못쓰게 됩니다.
GraphQL 개념 사용법 정리
#1. GraphQL 개념 및 개요
#2. GraphQL 소개
GraphQL 개념잡기