GraphQL은 Facebook이 2012년에 개발하고 2015년에 오픈 소스로 공개한 쿼리 언어(Query Language) 및 API 런타임입니다.
클라이언트가 원하는 데이터만 정확히 요청하고, 서버는 그에 맞춰 응답을 제공하는 방식으로, REST API의 한계를 보완하기 위해 설계되었습니다.
GraphQL의 장점
필요한 데이터만 요청 가능 → 성능 최적화
단일 API 엔드포인트로 유지보수 용이
프론트엔드 개발 효율성 증가
데이터 연관 관계 처리 용이
GraphQL의 단점 및 고려사항
캐싱 어려움
GET
요청 캐싱이 쉽지만, GraphQL에서는 쿼리 복잡도 때문에 캐싱이 어렵다.초기 학습 곡선
과도한 요청 가능성
보안 고려 필요
GraphQL 사용 사례
모바일 및 웹 애플리케이션
마이크로서비스 아키텍처
실시간 애플리케이션
클라이언트 중심 데이터 요청
클라이언트는 필요한 데이터만 요청하고, 서버는 정확한 데이터만 반환하여 불필요한 네트워크 사용을 최소화함.
Over-fetching(불필요한 데이터 요청)과 Under-fetching(데이터 부족)을 방지함.
예제
{
user(id: "123") {
name
email
profilePicture
}
}
단일 엔드포인트(Endpoint)
REST API에서는 여러 개의 엔드포인트(/users
, /products
등)를 사용하지만, GraphQL은 단일 엔드포인트(/graphql
)만 사용하여 모든 요청을 처리함.
유지보수가 쉬워지고, 클라이언트의 요청이 유연해짐.
타입 시스템(Type System)
GraphQL은 자체적인 스키마 언어(SDL, Schema Definition Language)를 사용하여 API의 데이터 구조를 명확하게 정의함.
예제
type User {
id: ID!
name: String!
email: String!
}
실시간 데이터 제공(Subscriptions)
subscription을 통해 WebSockets 등을 활용하여 실시간 데이터 업데이트 제공 가능
예제
subscription onNewMessage {
newMessage {
content
timestamp
}
}
계층형 데이터 페칭
API 응답이 계층적 구조(Hierarchical Structure)로 구성되어 있어, 클라이언트에서 복잡한 데이터를 한 번의 요청으로 받아올 수 있음.
예제
{
product(id: "1") {
name
price
reviews {
rating
comment
}
}
}
강력한 도구 생태계
GraphQL을 사용하면 클라이언트 및 서버에서 여러 툴을 활용하여 효율적으로 API를 관리할 수 있음.
스키마(Schema)
API의 구조와 가능한 쿼리, 데이터 유형을 정의하는 중심 요소
GraphQL 스키마는 type
, query
, mutation
, subscription
으로 구성됨.
예제
type Query {
getUser(id: ID!): User
}
type User {
id: ID!
name: String!
email: String!
}
쿼리(Query)
클라이언트가 데이터를 가져올 때 사용
SQL의 SELECT와 유사
예제
{
user(id: "123") {
name
email
}
}
뮤테이션(Mutation)
데이터를 생성, 수정, 삭제할 때 사용 (REST의 POST, PUT, DELETE와 유사)
예제
mutation {
createUser(name: "Alice", email: "alice@example.com") {
id
name
}
}
서브스크립션(Subscription)
실시간으로 데이터를 업데이트할 수 있도록 하는 기능 (WebSocket 기반)
예제
subscription {
onMessageAdded {
content
author
}
}
리졸버(Resolver)
GraphQL 서버에서 데이터를 어떻게 가져올지를 정의하는 함수
예제(Express + Node.js 기반)
const resolvers = {
Query: {
user: (_, { id }) => getUserFromDB(id),
},
};
비교 항목 | GraphQL | REST API |
---|---|---|
엔드포인트 개수 | 단일 엔드포인트 (/graphql ) | 여러 개의 엔드포인트 (/users , /posts ) |
데이터 반환 방식 | 클라이언트가 원하는 필드만 지정 | 고정된 데이터 반환 (필요 없는 데이터 포함) |
Over-fetching 방지 | 가능 (필요한 데이터만 요청) | 불필요한 데이터까지 포함될 수 있음 |
Under-fetching 방지 | 가능 (관련 데이터를 한 번에 요청) | 여러 번의 API 호출 필요 |
실시간 기능 지원 | 기본 제공 (Subscriptions) | 별도의 구현 필요 (WebSockets) |
유지보수 | 쉬움 | 상대적으로 어려움 |