GraphQL의 특징
Facebook에서 개발한 데이터 쿼리 언어로, API 요쳥을 최적화하는 것을 목적으로 한다.
GraphQL은 REST API의 대안으로 사용된다.
- 클라이언트 주도 데이터 요청: 클라이언트는 필요한 데이터의 구조를 정확히 지정해 요청할 수 있다. 따라서 불필요한 데이터 전송을 줄이고, 오버페칭(over-fetching)과 언더페칭(under-fetching) 문제를 해결할 수 있다.
- 단일 엔드포인트: 모든 요청이 단일 엔드포인트로 전송되기 때문에, 여러 엔드포인트를 사용할 필요 없이 다양한 데이터를 하나의 엔드포인트로 요청할 수 있다.
- 강력한 타입 시스템: 스키마를 사용하여 데이터의 구조를 명확하게 정의한다. 이를 통해 클라이언트와 서버 간의 데이터 일관성을 유지하고, 자동화된 문서화와 검증이 가능하다.
- 실시간 업데이트: 서브스크립션(Subscription)을 지원하여, 클라이언트가 실시간으로 데이터를 수신할 수 있다.
GraphQL의 동작 원리
GraphQL 서버는 스키마(schema)를 기반으로 작동하며, 클라이언트의 요청에 따라 데이터를 제공하거나 조작한다.
사용되는 문법은 Schema Definition Language(SDL) 이라고 부른다.
스키마는 쿼리(query), 뮤테이션(mutation), 서브스크립션(subscription) 세가지 주요 타입으로 구성되어있다.
- 쿼리(query): 데이터를 가져오는 요청
- 뮤테이션(mutation): 데이터를 수정하는 요청
- 서브스크립션(subscription): 데이터의 실시간 변화를 구독하는 요청
# 쿼리 스키마 예시(서버)
type User {
name: String!
email: String!
posts: Post
}
type Post {
title: String!
content: String!
}
type Query {
user(id: Int!): User
}
# 쿼리 요청 예시(클라이언트)
{
user(id: 1) {
name
email
posts {
title
content
}
}
}
해당 쿼리는 id가 1인 user의 name, email, posts 그리고 post의 title, content를 요청한다.
클라이언트는 필요한 필드를 지정할 수 있어, 정확히 필요한 데이터를 요청하여 네트워크 효율도 최적화할 수 있다.
* 문법에 대한 설명은 다음 글에서 진행할 예정입니다.
GraphQL VS REST API
데이터 요청 및 응답
- REST API
- 클라이언트는 정해진 엔드포인트에 요청을 보내고, 서브는 응답을 반환
- 데이터의 구조는 서버가 정의하고, 클라이언트는 서버가 반환하는 모든 데이터를 수신
- 요청은 HTTP 메서드(GET, POST, PUT, DELETE 등) 에 따라 구분
- GraphQL
- 클라이언트는 단일 엔드포인트로 요청을 보내고, 필요한 데이터의 구조를 직접 지정
- 클라이언트는 필요한 데이터만 요청할 수 있어, 불필요한 데이터 전송을 줄일 수 있다.
- 요청은 쿼리(query), 뮤테이션(mutation), 서브스크립션(subscription)으로 구분
데이터 전송 효율
- REST API
- 오버패칭(over fetching)과 언더페칭(under fetching)이 발생할 수 있다
- 오버패칭: 불필요한 데이터까지 전송
- 언더패칭: 추가 데이터를 위해 여러번 요청(게시물을 요청하고, 해당 게시물의 댓글을 추가로 요청)
- 여러 엔드포인트에 걸쳐 데이터를 요청
- 오버패칭(over fetching)과 언더페칭(under fetching)이 발생할 수 있다
- GraphQL
- 클라이언트는 정확히 필요한 데이터만 요청할 수 있어 데이터 전송이 효율적이다
- 단일 엔드포인트로 필요한 모든 데이터를 가져올 수 있다
스키마와 타입
- REST API
- 특정한 스키마나 타입이 없다.
- API 문서화와 데이터 검증을 위해 추가적인 도구나 규약이 필요
- GraphQL
- 강력한 타입 시스템과 스키마를 통해 데이터 구조를 명확히 정의
- 자동화된 문서화와 데이터 검증이 가능하며, 클라이언트와 서버간의 일관성을 유지
실시간 데이터
- REST API:
- 기본적으로 실시간 데이터 기능을 제공하지 않는다
- 이를 구현하기 위해서는 웹소켓, SSE(Server-Sent Events) 등의 추가적인 방법이 필요
- GraphQL:
- 서브스크립션을 통해 실시간 데이터 업데이트를 지원
캐싱
- REST API:
- HTTP 프로토콜의 기본적인 캐싱 메커니즘을 사용할 수 있다
- URL을 기반으로 한 리소스 접근 방식은 캐싱에 유리
- GraphQL:
- 응답 데이터의 유연한 구조로 인해 캐싱이 복잡할 수 있다
- 별도의 캐싱 전략과 도구가 필요할 수 있다
학습 곡선 및 복잡성
- REST API:
- 상대적으로 간단하며, HTTP와 RESTful 원칙을 이해하면 쉽게 접근할 수 있다
- 널리 사용되고 있어 많은 도구와 라이브러리가 지원
- GraphQL:
- 새로운 개념과 문법을 학습해야 하고, 초기 설정 및 스키마 설계가 복잡할 수 있다
- 강력한 기능을 제공하지만, 이를 제대로 활용하기 위해서는 추가적인 학습이 필요
사용 사례
- REST API:
- 단순한 CRUD 애플리케이션
- 예시: 블로그 플랫폼, 간단한 메모 애플리케이션
- 캐싱이 중요한 애플리케이션
- 예시: 콘텐츠 제공 네트워크(CDN), 뉴스 웹사이트
- 간단한 API 구조를 필요로 하는 애플리케이션
- 예시: 사내 도구, 내부 마이크로서비스 통신
- 단순한 CRUD 애플리케이션
- GraphQL:
- 복잡한 데이터 요구사항이 있는 애플리케이션
- 예시: Facebook, Twitter와 같은 소셜 미디어 플랫폼
- 다양한 클라이언트가 있는 애플리케이션
- 예시: 모바일 앱과 웹 앱을 동시에 제공하는 서비스
- 실시간 데이터 업데이트가 필요한 애플리케이션
- 예시: 실시간 채팅 애플리케이션, 주식 거래 플랫폼
- 복잡한 데이터 요구사항이 있는 애플리케이션