GraphQL
페이스북이 개발한 오픈 소스 쿼리언어이다. API를 위한 쿼리 언어이며 클라이언트 요청에 따라 유연하게 트리 구조의 JSON 데이터를 응답으로 전송할 수 있다. 모든 데이터가 그래프 형태로 연결되어 있다고 전제하며 GraphQL로 그래프를 순회하는 과정은 다음과 같다.
도서관의 도서 목록 시스템을 구축한다고 가정한다면 많은 책과 저자, 공동저자 등의 관계를 그래프 형태로 시각화할 수 있다. 이런식으로 그래프를 표현하게 되면 우리가 가지고 있는 데이터의 조각들이 나타내고자 하는 엔티티 간의 관계를 나타낼 수 있다.
엔티티는 사물의 구조나 상태, 동작 등을 모델로 표현하는 경우, 그 모델의 구성요소를 말합니다. 예를 들어 학생이라는 객체는 “학번”, “이름”, “학과”라는 3개의 속성으로 구성되어 있는 것처럼, 위의 엔티티는 책이라는 객체가 존재한다면 “책이름"이라는 1개의 속성으로 구성되어 있는 셈입니다.
정보의 측면에서 볼 때 이 속성은 그 자체만으로는 중요한 의미를 표현하지 못하기 때문에 단독으로 존재하지는 못합니다. 앞의 예에서 각 속성들 즉 “학번”, “이름”, “학과”는 개별적으로는 우리에게 어떤 정보를 제공해 주지 못하지만 이것들이 모여 “학생”이라는 객체를 구성해서 표현할 때는 큰 의미를 제공할 수 있게 됩니다.
그래프에서 트리 추출하는 방법
위의 그래프에서 실행할 수 있는 쿼리는 다음과 같다.
query {
책(ISBN이 "9780674430006") {
책 이름
저자 {
이름
}
}
}ISBN이 "9780674430006"인 조건을 걸어 주었다. 이 방식으로 서버에 요청을 보내면 서버가 요청을 해결하여 돌아온 쿼리는 다음과 같다
{
책 : {
책 이름 : "GraphQL은 어렵지 않다",
저자 : [
{ 이름 : "김코딩"},
{ 이름 : "박해커"},
]
}
}이를 그래프의 관점에서 본다면 다음과 같다
ISBN 번호를 사용하여 선택한 '책' 노드에서 시작하여 중첩된 각 필드로 표시된 간선을 따라 그래프를 탐색하기 시작한다. 쿼리 내 중첩된 '책 이름' 필드를 통해 책의 제목이 있는 노드로 이동하고 '저자'로 레이블이 지정된 '책' 간선을 따라가 '저자' 노드를 가져오고 각 저자의 '이름'을 얻어오는 것이다.
GraphQL의 특징
GraphQL은 HTTP를 통해 API 서버로 요청을 보내고 응답을 받습니다.
응답을 받을 시, 데이터 결과를 JSON 형식으로 받습니다.
GraphQL은 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있습니다.
GraphQL은 GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사합니다.
GraphQL VS REST API
이전에 이미 REST API라는 방법론이 존재함에도 GraphQL을 쓰는 이유는 무엇인지 알아보자.
REST API의 한계
Overfetch : 필요 없는 데이터까지 제공함
Underfetch : endpoint가 필요한 정보를 충분히 제공하지 못함
클라이언트는 필요한 정보를 모두 확보하기 위해 추가적인 요청을 보내야 하며 REST API에서는 각각의 자원에 따라 엔드포인트를 구분하기 때문에 1개 이상의 엔드포인트에 요청을 보내야 합니다.
REST API에서는 자원의 크기와 형태를 서버에서 결정하기 때문에 클라이언트 구조 변경 시 엔드포인트 변경 또는 데이터 수정이 필요하다.
REST API와 GraphQL의 차이점
결론적으로 REST API에 비해 GraphQL은 정보를 사용하는 측에서 원하는 대로 정보를 가져올 수 있고 보다 편하게 정보를 수정할 수 있다.
GraphQL의 장단점
장점
1. 하나의 endpoint 요청
/graphql 이라는 하나의 endpoint로 요청을 받고 그 요청에 따라 query, mutation을 resolver 함수로 전달하여 요청에 응답한다. 모든 클라이언트 요청은 POST 메소드를 사용
2. No! under & overfetching
여러개의 endpoint 요청을 할 필요 없이 하나의 endpoint에서 쿼리를 이용해 원하는 데이터를 정확하게 API에 요청하고 응답으로 받을 수 있다.
3. 강력한 playground
POSTMAN과 비슷하며 GUI를 이용해 resolver와 schema를 한눈에 보고 테스트해볼 수 있다.
4. 클라이언트 구조 변경에도 지장이 없음
클라이언트 구조가 바뀌어도 필요한 데이터를 결정하고 받는 주체가 클라이언트이기 때문에 서버에 지장이 없다. 클라이언트에서는 무슨 데이터가 필요한지 요구사항을 쿼리로 작성하면 된다.
단점
- REST API에 익숙한 개발자의 경우 학습하는데 시간이 필요하다
- 캐싱이 REST보다 훨씬 복잡하다 POST 메소드만을 이용해 요청을 보내기 때문에 각 메소드에 따른 캐싱을 지원받을 수 없다. 이를 보완하기 위해 Apollo 엔진의 캐싱과 영속 쿼리등이 등장하였다.
- 고정된 요청과 응답만 필요한 경우에는 Query로 인해 요청의 크기가 RESTful API보다 더 커진다.
다음으로 GraphQL 실습을 통해 구조 및 문법, 다루는 방법 등을 배워보자.
