2025-08-30 01:11
Tags: 소프트웨어 공학
GraphQL
-
기존 REST 방식에서 생기는 오버페칭과 언더페칭 없이 정확히 필요한 데이터만 가져올 수 있다.
-
스키마
- 서버가 어떤 데이터를 제공할 수 있는지, 클라이언트가 어떤 데이터를 요청할 수 있는지 타입으로 정의
- 기능 정의하는 설계도 또는 타입 시스템
# 사용자를 나타내는 타입 type User { id: ID! name: String! email: String } # 게시물을 나타내는 타입 type Post { id: ID! title: String! content: String! author: User! # 게시물 작성자는 User 타입 } # 클라이언트가 데이터를 요청(Query)할 때 사용할 수 있는 진입점 type Query { post(id: ID!): Post allUsers: [User!] }
-
쿼리 (READ)
- 뮤테이션 (CREATE UPDATE DELETE)
mutation {
createUser(name: "이순신", email: "lee@example.com") {
id
name
}
}
| 특징 | REST | GraphQL |
| ------------- | ------------------------------------------ | ----------------------------------- |
| **엔드포인트** | 여러 개의 엔드포인트 (e.g., `/users`, `/posts/:id`) | 단 하나의 엔드포인트 (e.g., `/graphql`) |
| **데이터 요청** | 서버가 정의한 자원 구조대로 전체 데이터를 받음 | 클라이언트가 필요한 데이터의 구조를 직접 정의하여 요청 |
| **오버페칭/언더페칭** | 발생 가능성이 높음 | 근본적으로 해결 |
| **요청 방식** | HTTP 메서드(GET, POST, PUT, DELETE)로 동작 구분 | `query`(읽기)와 `mutation`(쓰기)으로 동작 구분 |
| **타입 시스템** | 별도의 타입 시스템이 없음 (OpenAPI 등으로 보완) | 강력한 타입 시스템(스키마)을 내장하여 안정성 확보 |
| **문서화** | 별도의 도구(e.g., Swagger) 필요 | 스키마 자체가 API 문서 역할을 하여 자동 문서화 가능 |
## 언급한 노트 (Outgoing Links)
- [[5-💎 영구 노트/타입\|타입]]
- [[5-💎 영구 노트/클라이언트\|클라이언트]]
- [[5-💎 영구 노트/쿼리\|쿼리]]
- [[5-💎 영구 노트/서버\|서버]]
- [[5-💎 영구 노트/REST\|REST]]
- [[5-💎 영구 노트/API\|API]]
- [[3-🏷️ 태그/소프트웨어 공학\|소프트웨어 공학]]
## 백링크 (Backlinks)
- [[1-📚 참고 노트/ai 답변/GraphQL 완벽 정복 핸드북 API의 미래를 만나다\|GraphQL 완벽 정복 핸드북 API의 미래를 만나다]]
- [[1-📚 참고 노트/ai 답변/GraphQL 완벽 핸드북 REST API를 넘어선 새로운 시대\|GraphQL 완벽 핸드북 REST API를 넘어선 새로운 시대]]
- [[5-💎 영구 노트/API\|API]]