GraphQL은 클라이언트가 서버로부터 데이터를 요청하는 방식 중 하나다. 기존에 존재하는 REST API와 역할이 비슷하다.
REST API와 차이점
OverFetching
GraphQL은 요청(request)에 자신이 원하는 항목을 명시하면 응답(response)에 해당 항목만 반환되기 때문에 네트워크 대역폭을 절약할 수 있다. 대신 가변 요청을 처리하기 위해 GraphQL 요청엔 약간의 오버헤드 데이터가 있다. 반면 REST API는 엔드포인트 별로 항상 일정한 응답이 반환되기 때문에 필요없는 데이터도 반환될 수 있다.
UnderFetching
GraphQL은 엔드포인트가 1개이기 때문에 HTTP 요청 1번에 원하는 데이터를 모두 가져올 수 있다. 하지만 REST API는 일반적으로 데이터 종류별로 엔드포인트가 존재하기 때문에 원하는 데이터의 엔드포인트마다 일일이 HTTP 요청을 해야 한다.
Type
GraphQL은 요청과 응답에 대해 자료형 지정이 가능하다. 그래서 허용되지 않은 자료형 데이터가 요청으로 들어오면 응답이 거부되고, 클라이언트는 응답 데이터의 자료형을 명확하게 알 수 있다. 쉽게 말해 GraphQL의 장단점은 JavaScript에 비해 TypeScript가 가지는 장단점과 비슷하다.
Cross Platform
GraphQL은 웹, 안드로이드, iOS 등 클라이언트 별로 API를 만들 필요 없이 1개만 만들면 된다. 모바일은 안 써봐서 잘 모르겠지만 그렇다고 한다.
위 4개가 실질적인 차이점이다. 아래는 서로 비슷한 부분이다.
REST API와 비슷한 점
엔드포인트
GraphQL은 엔드포인트가 1개이기 때문에 엔드포인트를 따로 유지보수할 필요가 없다. 하지만 반대로 말하면 클라이언트가 서버 API의 요청 가능 함수를 제대로 숙지하고 있어야 한다는 뜻이다. 반면 REST API는 엔드포인트를 따로 관리해야 한다. 즉, GraphQL은 서버 API의 함수 이름을 관리해야 하고, REST는 엔드포인트를 관리해야 한다.
스키마
REST는 따로 API 문서를 작성하고 관리해야 하지만, GraphQL은 엔드포인트에서 제공하는 스키마 파일을 통해 서버 API 함수의 종류와 자료형을 알 수 있다. 하지만 따지고 보면 GraphQL도 누군가는 스키마 파일을 관리해야 된다. 즉, REST는 API 문서를 직접 작성해야 하고, GraphQL은 스키마 파일을 직접 작성해야 한다.
쿼리-뮤테이션
GraphQL의 Query는 REST API의 GET과 비슷하고, GraphQL의 Mutation은 REST API의 POST, PUT, DELETE와 비슷하다.
파일 전송
REST API와는 다르게 GraphQL은 자체적으로 텍스트 전송만 지원하고 파일 전송을 지원하지 않는다. 물론 파일을 텍스트로 표현할 수 있기 때문에 외부 라이브러리를 사용하면 파일 전송이 가능하다. 결과적으론 둘 다 파일 전송을 지원한다.
캐싱
REST API는 엔드포인트가 여러 개이기 때문에 각 데이터 요청에 대해 HTTP 캐싱을 그대로 활용할 수 있다. 하지만 GraphQL은 엔트포인트가 1개이기 때문에 HTTP 캐싱을 그대로 이용할 순 없고 다른 캐싱 기법(Apollo client 등)이 필요하다. 결과적으론 둘 다 캐싱을 지원한다.
