1. GraphQL이란?

GraphQL은 API용 쿼리 언어이자 기존 데이터로 이러한 쿼리를 수행하기 위한 런타임입니다. GraphQL은 API의 데이터에 대한 완전하고 이해하기 쉬운 설명을 제공하고, 클라이언트가 필요한 것을 정확하게 요청할 수 있는 기능을 제공하며, 시간이 지남에 따라 API를 더 쉽게 발전시키고 강력한 개발자 도구를 활성화합니다. -GraphQL 공식홈페이지

GraphQL은 우선 SQL과 마찬가지로 쿼리 언어이다. 하지만 그래프큐엘과 SQL의 사용성 측면에서 큰 차이가 있다. 우선 SQL은 데이터베이스에 저장된 데이터를 효율적으로 가져오는 것이 목적이지만, 그래프큐엘은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적이다. 그래서 SQL은 백엔드에서 작성 및 호출하지만 그래프큐엘은 클라이언트에서 작성하고 호출한다. 그렇기 때문에 그래프큐엘이 대체하는 것은 기존의 쿼리 언어들이 아닌 REST API이다.

그렇다면 프론트엔드에서 무엇이 불편했길래 메타(구 페이스북)는 그래프큐엘이라는 쿼리 언어를 만들었고 사람들은 그래프큐엘을 사랑하게 되었는지 알아보자.

2. GraphQL이 나오게 된 배경

기존의 REST API는 리소스와 URI를 조합하여 요청을 보내면 이에 대응하는 응답을 JSON이나 XML 형식으로 넘겨주었다. REST API의 가장 큰 강점은 예측 가능하고 일정한 정보와 작업을 요청하는 것이였다. 하지만 여기서 생기는 문제는 정해진 응답만을 받을 수 있다는 것이다. 예를 들어 A의 전화번호 정보를 받기위해서 A의 모든 정보를 받아야할 수 있다. 이렇게 필요없는 정보까지 받기 위해서 불필요한 리소스(시간, 통신비)가 생긴다.(Overfatching) 이러한 다른 모양의 다양한 요청과 응답이 필요한 서비스들이 많이 생겨났고 그로인한 리소스들을 줄이기 위해서 GraphQL이 각광받게 되었다.

REST API vs GraphQL

REST API는 URL과 METHOD 등을 조합하여 사용하기 때문에 필연적으로 많은 Endpoint가 존재한다. 하지만 그래프큐엘은 하나의 Endpoint만 존재한다. 그렇기 때문에 REST API에서는 각 Endpoint마다 데이터베이스 SQL 쿼리가 달라지지만 그래프큐엘은 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라진다.

그러므로 위의 그림처럼 그래프큐엘은 네트워크를 여러번 호출(Underfatching)을 할 필요없이 쿼리 언어를 직접 작성하여 한번의 네트워크 호출로 원하는 데이터들을 받아올 수 있다.

3. GraphQL의 구조

3-1. Query 쿼리 / Mutation 뮤테이션

REST API의 경우에는 데이터 CRUD를 하기위해 get, post, put, delete를 사용하지만 GraphQL은 Query와 Mutation 두 가지만 사용한다. 데이터를 Read를 할 때는 Query를 사용하고 Create, Update, Delete를 하기 위해서 Mutation을 사용한다.
하지만 그래프큐엘 내부적으로 Query와 Mutation은 차이가 거의 없다. 그렇기 때문에 쿼리로 데이터를 수정할 수 있다. 그렇지만 변경을 발생시키는 작업은 명시적으로 뮤테이션를 이용해서 전송되어야 한다는 규칙을 지키는 것이 좋다.

Example

Query(요청 쿼리 / 응답 데이터)

위 그림과 같이 쿼리와 받은 데이터는 동일한 형태이다. 이렇게 명확하고 직관적인 응답 데이터를 받을 수 있는 이유는 그래프큐엘을 통해 서버가 클라이언트가 원하는 필드를 정확히 알 수 있기 때문이다.

Mutation(요청 뮤테이션 / 응답 데이터)

createReview 필드가 새로 생성된 리뷰의 stars 와 commentary 필드를 반환한다. 이는 하나의 요청으로 필드의 새 값을 변경하고 쿼리할 수 있기 때문에 기존 데이터를 변경하는 경우 특히 유용하다.

프래그먼트(요청 쿼리)

우리가 가져오려는 데이터의 형식이 너무 복잡하고 이 필드를 여러번 반복해서 사용해야한다면 우리는 프래그먼트를 사용할 수 있다. 프래그먼트 개념은 주로 복잡한 응용 프로그램의 데이터 요구사항을 작은 단위로 분할하는데 사용된다. 리액트에서 컴포넌트화하는 것을 연상하면 이해하기 쉬울 것이다.

3-2. Introspection 인트로스펙션

기존의 서버와 클라이언트의 협업 방식에서는 API 명세서를 주고 받는 절차가 필요하다.이러한 절차는 당연히 그에 맞는 리소스를 잡아먹게 된다. 만약 API 명세서를 제대로 업데이트하지 않는다면 그것은 큰 문제를 야기할 수 있다.
이러한 REST의 API 명세서 생성 자동화하는 것이 그래프큐엘의 인트로스펙션 기능이다. 그래프큐엘의 인트로스펙션은 서버에서 정의된 스키마의 정보를 생성 및 공유할 수 있게한다.

위 사진은 그래프큐엘 라이브러리에서 제공하는 플레이그라운드라고 불리는 쿼리용 IDE이다. 플레이그라운드에서 직접 쿼리 및 뮤테이션, 필드 스키마를 확인 할 수 있다. 물론 상용환경에서는 이러한 스키마의 공개한다면 보안 이슈가 존재한다. 그러므로 해당 기능을 끄는 옵션을 사용하여 상용환경에서는 끄는 것을 권장한다.

4. 정리

장점

• 그래프큐엘은 기존의 REST API가 필요한 데이터를 받기 위해서 여러번 요청을 보내야 했던 것(Underfetching)을 한번의 요청으로 받아올 수 있다.
• 필요하지 않은 데이터까지 포함된 데이터 덩어리를 받아오지(Overfetching) 않고 원하는 데이터만 선택적으로 받아올 수 있다.
• 가장 큰 장점은 인트로펙션 기능을 통해서 API 명세의 공유가 자동화 된다는 점이다. 이 부분은 개발의 생산성이 향상되어 백엔드 - 프론트엔드의 협업이 더 쉬워질 것이다.

단점

• File 전송 등 Text 만으로 하기 힘든 내용들을 처리하기 위해서는 외부 서비스에 의존하거나 복잡해진다.
• 고정된 요청과 응답만 필요할 때는 Query 요청의 크기가 REST API 보다 더 커진다.

마무리

오늘 알아본 결과 그래프큐엘은 매우 훌륭하고 좋은 언어이자 서비스지만 만능은 아니다. 어떤 정보를 제공하느냐에 따라 REST API와 그래프큐엘의 효율성이 왔다갔다한다.

서로 다른 모양의 다양한 요청과 응답이 많다면 그래프큐엘이 효율적이지만 HTTP와 HTTPS에 의한 캐싱을 잘 활용하고 싶거나 요청의 구조가 정해지지 않았을 때는 REST API가 효율적일 가능성이 높다.

하지만 하나의 솔루션만을 선택할 필요없이 백엔드 서버에 두가지 솔루션을 모두 사용할 수 있다. 그러니 우리는 새로운 도구를 얻었고 기존의 도구와 잘 활용한다면 더 나은 서비스를 제공할 수 있을 것이다!!