[GraphQL] 1. GraphQL이란?

1. GraphQL 정의

- RESTful API와 같은 선상이라고 보는 것이 이해하기 좋다. (정확히는 RESTful의 하위다. POST 통신의 Data 구간에 요청 쿼리를 전달한다.)
- *클라이언트와 서버 간의 통신 명세다.
- 페이스북에서 내부적 성능 개선을 목적으로 만들었다.
- 선언형 데이터 페칭 언어(Declarative Data Fetching Language)다. 어떤 데이터가 필요한지에 중점을 두고, 어떻게 가져올지에 대한 것은 신경쓰지 않는다.

2. GraphQL이 생긴 이유

RESTful API의 단점을 해결하기 위해 만들어졌다. 
단점 1. 오버페칭(Overfetching)
- 클라이언트가 필요로 하는 데이터보다 많은 데이터를 반환 받는 상황을 말한다. 요구사항의 추가 및 여러 페이지에서 1개의 api를 사용하는 경우, RESTful API 서버에서는 필연적으로 발생한다.

 

단점 2. 언더페칭(Underfetching)
- 1개의 웹 페이지에서 필요로 하는 데이터를 준비하기 위해, n개의 api를 호출해야 하는 상황을 말한다.

 

단점 3. RESTful API 서버 엔드포인트 관리 (api 개수 = uri 개수)
- 서버 운영 및 유지 보수 시에 변경/추가 기능이 생기면 api 라우팅을 새로 만들어서 사용하는 경우가 많다. (유사 기능이라고 해도 개발/운영 편의성을 위해 새로 만들어 사용하는 경우가 생각보다 많다.)

위 3가지 단점을 보완하기 위해
1. GraphQL로 필요로 하는 파라미터만을 질의하여, 질의한 데이터 구조 그대로 반환 받는다.
2. 중첩 GraphQL을 작성하여, api를 1회 호출하여 필요로 하는 데이터를 받을 수 있도록 한다.
3. GraphQL 서버는 서버 엔드포인트(라우팅 uri)를 하나로 설계된다. (엔드포인트를 기준으로 호출하지 않기 때문에 가능하다.)

 

*3번의 경우, RESTful API 서버에서는 [도메인 + endpoint]를 기준으로 호출하지만 Graphql은 쿼리 내부에 어떤 데이터를 불러올지를 담기 때문에 uri를 통한 endpoint를 따로 만들어줄 필요가 없다(Graphql로 데이터를 호출하면 바로 이해가 가는 부분이었다).
-> 서버 개발의 생산성면에서 작업을 줄일 수 있다. Controller와 Service를 관리하던 서버 개발자의 작업 중 Controller의 작업을 줄일 수 있게 되었다. (근데 마냥 그렇지만도 않다. 결국 호출 쿼리 이름을 지어줘야 한다.)

* "GraphQL이 RESTful을 망하게하는 것이 아니라 RESTful의 약점을 보완하기 위한 수단"이라고 보는 것이 좋다고 한다. 
처음부터 GraphQL을 기반으로 개발한 경우가 아닌, RESTful api 서버에 GraphQL을 연동한 곳도 많다고 서술되어 있다.

 

* RESTful과 GraphQL 2중 구성으로 만들 수도 있다. 서버 로직의 핵심이 되는 서비스 코드는 동일하기에 접근 방식만 허용해주면 된다.