1️⃣ overfetching 개선
REST API - 전송에 사용된 HTTP 메소드 URL를 통해 작업을 구분한다. 이는 많은 엔드 포인트를 관리해야 하고 대상에 대한 데이터를 요청할 수 있지만, 데이터의 각 항목을 세분화하여 받아 올 수 없는 단점이 있다.
예를 들어 위의 예시와 같이 책의 제목과 작가만 보여주는 페이지에서도 책에 대한 모든 데이터를 받아와야 한다.
즉, 필요 이상의 데이터가 전송되는 overfetching 문제가 발생한다. 서비스에는 많은 데이터 요청일 필요하기 때문에 이 과정에서 데이터 낭비 및 오버헤드가 발생한다.
GraphQL - 하나의 포인트를 사용하며 모든 요청은 POST를 통해 전달하기 때문에 엔드포인트 관리 용이하다느 장점이 있다. 또한 데이터 요청 시 원하는 데이터의 항목을 직접 지정하여 받아올 수 있다. 예를 들어 책의 제목과 작가 이름을 보여주는 페이지의 경우, 제목과 작가 정보만 요청하고 해당 요청에 대한 응답만 받을 수 있다.
즉, 클라이언트가 원하는 정보만 선택 응답 받을 수 있다.
2️⃣ Underfetching 문제 개선
위와 같이 책의 정보와 해당 리뷰, 리뷰어에 대한 이름을 보여주는 화면의 경우,
REST API - 책의 정보, 리뷰들의 정보, 리뷰를 올린 사용자의 정보 각각 다른 요청을 통해서 받아야한다.
이는 한 화면을 보여주기 위해 여러차례의 요청을 보내야하는 문제, 하나의 요청으로는 충분한 데이터를 받아오지 못하는 Underfetching 문제가 있다.
GraphQL - 한 번의 요청으로 책의 정보, 리뷰 정보, 사용자의 정보만 받을 수 있다. 즉, 원하는 정보만 선택 응답을 받을 수 있다.
3️⃣ 구독 기능
REST API - 데이터의 업데이트 된 데이터를 보여주기 위해서 REST API는 서버에 계속 요청을 보내어 업데이트 여부를 확인해야 한다.
GrapQL - 특정 리소스에 데이터가 업데이트될 때마다 알림을 받을 수 있어 데이터의 업데이트 확인을 위한 요청을 할 필요가 없다.
4️⃣ 스키마
GrapQL이 사용되는 서비스에서 어떤 데이터들이 사용될 수 있고 어떤 요청 및 구독이 전달 실행될 수 있는지 정의해둔 계획도이다.
왼편에는 서비스에서 사용될 리소스들이 각각 타입으로 정의되고 각 타입에는 어떤 데이터가 포함되어 있는지 나와있다.
이들을 통해서 어떤 쿼리, 큐테이션, 구독을 구현할 수 있는지 오른편에 정의된다.
작업을 선언한 것으로 구현하는 코드는 언어 환경, 라이브러리에 따라 작성하면 된다.
5️⃣ 단점
캐싱의 어려움
요청들이 복잡한 GrapQL 메세지로 되어 있고, GraphQL은 클라이언트가 요청하는 필드와 구조가 매번 다를 수 있기 때문에 캐싱 전략을 적용하기가 어렵다.
서버 부담
GrapQL 서비스는 성능 문제 복잡한 쿼리를 해석해서 실행한다. 이는 복잡한 쿼리가 많아질수록 이 과정에서 서버의 CPU와 메모리 사용량이 증가하여, 서버에 큰 부담을 줄 수 있습니다.
6️⃣ 적합 서비스
복잡하고 방대한 데이터 모델을 가진 서비스에서는 데이터를 유연하게 쿼리할 수 있기 때문에 성능을 최적화할 수 있다.
클라이언트가 데이터 요청에 많은 제어권을 가진 서비스에서는 필요한 데이터를 정확히 요청하고, 응답받은 데이터를 최적화하여 사용할 수 있기 때문에 유용하다.
데이터의 업데이트에 대한 실시간 반응이 필요한 서비스에서는 GraphQL의 구독 기능을 활용해 실시간으로 데이터를 업데이트 받을 수 있기 때문에 효율적이다.
‘얄팍한 코딩사전 - GraphQL - 한 방에 이해하기’을 참고하여 정리하였습니다.
