1. 기술 소개
GraphQL이란 클라이언트와 서버 간의 api를 위한 쿼리 언어이다. 사전에 리소스와 관리 방식 정의하면, Rest 방식과 달리 클라이언트 측에서 원하는 데이터만 조회할 수 있다!
- 관리 방식은 read 역할을 하는 query와 cud 역할을 하는 mutation, 구독 개념의 subscription으로 나누어진다.
예를 들어 아래와 같이 리소스와 query를 정의해 보자.
type Book {
id: ID
title: String
author: Author
}
type Author {
id: ID
firstName: String
lastName: String
books: [Book]
}type Query {
book(id: ID!): Book
author(id: ID!): Author
}
그러면 아래처럼 Query의 모든 파라미터를 채우지 않고, 조회하고 싶은 데이터만 넘겨서 받을 수 있다!
// 쿼리
query {
book(id: "1") {
author {
firstName
}
}
}
// 결과
{
"title": "Black Hole Blues",
"author": {
"firstName": "Janna"
}
}2. REST 방식과의 차이점
1) 데이터 조회 방식의 차이
REST API에서는 한 페이지에서 여러 리소스를 조회하기 위해, 아래와 같이 여러 api를 호출해야 한다.
반면에 GraphQL에서는 아래와 같이 단일 쿼리로 조회할 수 있다. 번거롭게 api를 여러 번 호출하고 데이터를 가공하는 단계를 클라이언트가 부담하지 않아도 된다.
2) 오버 페칭과 언더 페칭
오버 페칭이란 불필요한 데이터까지 조회하는 것을 말하고, 언더 페칭이란 특정 api가 필요한 정보가 누락되어 있는 것을 의미한다. 언더 페칭의 경우 추가 요청을 필요하다는 비효율성이 존재한다.
REST 방식에서는 오버 페칭과 언더 페칭이 일반적인 문제이다. GraphQL은 원하는 데이터만 가져올 수 있기 때문에 그러한 문제를 고민하지 않아도 된다.
3. 마치면서
이러한 장점들이 존재하지만, 캐싱의 복잡함과 같은 단점들도 존재한다. 또한, GraphQL 서버 뒤에서 REST API를 추상화해서 사용할 수도 있기 때문에 이러한 장단점들들 잘 고려해서 도입해 보자.
- 캐싱에 복잡함에 대해서, REST API의 경우에는 URL을 식별자로 캐싱하면 된다. 하지만 GraphQL의 경우에는 동일한 리소스에 대해 각 쿼리가 다를 수 있으므로 캐싱이 복합하다. 다만, GraphQL 위에 구축된 대부분의 라이브러리는 효율적인 캐싱 메커니즘을 제공한다.
참고 링크
- https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60cfa683511
- https://hwasurr.io/api/rest-graphql-differences/
- https://www.javatpoint.com/graphql-advantages-and-disadvantages