Intro
현재 담당하는 프로젝트에서도 API 서버를 분리하여 GraphQL을 사용하고 있고, 사이드 프로젝트처럼 소규모 서비스 개발에도 REST API 보다 이점이 있을것이라 생각하여 GraphQL에 대해 스터디를 하게 되었습니다.
요즘의 웹서비스는 대부분 REST API 형태로 만들어져 있습니다. 기존의 레거시 프로젝트들도 REST로 많이 리팩토링 되었고 API는 당연하게 RESTful 하게 만드는 것이 당연해보입니다. 하지만 이러한 REST API에 맞서(?) GraphQL이 새롭게 떠오르고 있습니다.
GraphQL
GraphQL 이란?
GraphQL은 이름에서도 알 수 있듯이 SQL 같은 쿼리 언어입니다. API를 만들 때 사용할 수 있으며 기존의 REST API와 비교해 몇 가지 장점들이 있습니다.
먼저 GraphQL의 형태를 보면 요청과 응답의 JSON 형태가 같은 것을 볼 수 있습니다.
원하는 데이터의 형태를 쿼리로 정의하는 것 뿐만 아니라 쿼리문을 중첩하여 연관된 객체를 한번에 응답 받을 수도 있습니다.
하나 이상의 객체 데이터를 받기 위해서 여러번 요청하지 않아도 됩니다. 또한 불필요한 데이터를 받을 필요도 없습니다.
이러한 특징 때문에 GraphQL은 선언형 데이터 페칭 언어라고 일컬어집니다. 개발자는 필요한 데이터에 대한 요구사항만 쿼리를 통해 작성하면되고 어떻게 가져올지는 신경 쓰지 않아도 됩니다.
GraphQL 설계원칙
GraphQL API 작성법에 제한은 없으나 몇 가지 지침이 있습니다.
- 위계적
필드 안에 다른 필드가 중첩될 수 있으며, 쿼리와 그에 대한 응답 데이터는 형태가 서로 같다. - 제품 중심적
클라이언트가 요구하는 데이터와 클라이언트가 지원하는 언어 및 런타임 환경에 맞춰 동작한다. - 타입 제한
GraphQL 서버는 타입 시스템을 사용한다. 스키마의 데이터 포인트마다 특정 타입이 명시되며, 이를 기초로 유효성 검사를 받게 된다. - 클라이언트 맞춤 쿼리
클라이언트 쪽에서 받아서 사용할 수 있는 데이터를 제공한다. - 인트로스펙티브
GraphQL 서버가 사용하는 타입 시스템에 대한 쿼리를 작성할 수 있다.
GraphQL 과 REST API
GraphQL 은 REST 의 단점들을 보완하면서 등장하였습니다. 단점을 보완했다고 무조건 GraphQL 이 더 좋은 시스템이고 REST가 사라져야 한다는 것은 아닙니다.
웹이 계속 발전해 나가면서 REST가 특정 조건에서 부하가 걸리는 조짐이 보였고, GraphQL 은 이런 부하를 완화하고 보완할 수 있다고 생각하는 것이 더 맞습니다.
REST의 단점
- Overfetching
원하지 않는 데이터까지 응답 받는 경우를 의미합니다.
REST는 서버에 정의된 응답형태를 벗어날 수 없습니다.
자동차의 이름, 색, 마력만 알고 싶거나 이름, 색, 배기량을 알고 싶은 경우 각각의 요구에 대한 엔드포인트를 정의하지 않는다면 자동차DTO를 응답받게 됩니다.
원하는 필드는 3개이지만 서버에서 정의된 20개의 필드를 모두 응답받아야 하는 경우도 있습니다.
이는 오버페칭의 전형적인 케이스입니다.
이런 경우 전송에 필요한 네트워크 리소스와 데이터를 처리해야 하는 클라이언트 등 리소스의 낭비로 이어지게 됩니다. - Underfetching
오버페칭과는 반대로 원하는 데이터를 한번에 가져오지 못하는 경우를 의미합니다.
'현대' 라는 브랜드 객체에 담긴 자동차 리스트를 가져오기 위해서는 여러번 API를 호출해야 합니다.
GET localhost:8080/api/brands
GET localhost:8080/api/brands/{id}
GET localhost:8080/api/cars/{brandsId}
해당 요구사항에 대한 별도의 엔드포인트가 없다면 아마 위의 API를 거쳐야 원하는 데이터를 얻을 수 있을 것입니다. - 엔드포인트
위의 두 단점을 REST에서 극복하는 방법은 필요한 요구사항에 대한 모든 엔드포인트를 정의하는 것입니다. 개발의 범위가 넓어지고 유지보수해야할 코드가 늘어난다는 의미입니다.
API 요구사항이 추가될 때마다 엔드포인트 또한 추가되어야하고 스키마의 복잡도에 따라 서비스단이 무거워지게 됩니다.
