GraphQL이란?
GraphQL은 API를 위한 오픈 소스 쿼리 언어로, 2012년 페이스북에 의해 처음 개발되었고 2015년에 공개되었습니다. 클라이언트가 필요한 특정 데이터만 요청할 수 있도록 하여, 전통적인 REST API의 과도한 데이터 요청(over-fetching) 및 부족한 데이터 요청(under-fetching) 문제를 해결함으로써 유연하고 효율적인 대안을 제공합니다.
GraphQL의 인기가 높아지는 이유 중 하나는 클라이언트 주도적인 특성입니다. 이는 성능, 확장성 및 원활한 사용자 경험이 중요한 현대 애플리케이션에 특히 적합합니다. GraphQL은 클라이언트가 여러 리소스를 하나의 요청으로 결합할 수 있도록 하여 네트워크 트래픽을 줄이고, 대역폭이 제한된 모바일 앱이나 복잡한 프론트 엔드 요구 사항이 있는 경우에 훌륭한 솔루션이 됩니다.
GitHub, Twitter, Indeed, Shopify와 같은 주요 기업들이 GraphQL을 채택하여 API 개발을 간소화하고 클라이언트-서버 상호작용을 개선할 수 있는 잠재력을 강조하고 있습니다.
GraphQL 인터페이스
GraphQL에서 인터페이스는 객체 지향 프로그래밍의 인터페이스와 유사하게 작동합니다. 이는 여러 객체 타입이 구현할 수 있는 공통 필드 집합을 정의하는 추상 타입입니다. 이를 통해 클라이언트는 서로 다른 타입에서 이러한 공통 필드를 자신 있게 쿼리할 수 있습니다.
type Query {
findVehicles(): [Vehicle!]!
}
interface Vehicle {
id: ID!
name: String!
model: String
}
type Car implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Car
fuelType: String!
}
type Bicycle implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Bicycle
gearCount: Int!
isElectric: Boolean!
}
GraphQL 클라이언트 쿼리:
query findVehicles() {
findVehicles() {
vehicle {
id,
name,
model,
... on Car {
fuelType
}
... on Bicycle {
gearCount,
isElectric
}
}
}
}
이 예에서는 id, name, 그리고 model과 같은 공통 필드가 Vehicle 인터페이스를 구현하는 모든 객체 유형에서 사용할 수 있습니다. 그러나 Car에 대한 fuelType 및 Bicycle에 대한 gearCount 및 isElectric과 같은 유형별 필드는 조각을 사용하여 쿼리할 수 있습니다.
만약 클라이언트가 공통 필드만 필요한 경우, 조각을 생략할 수 있습니다:
query findCars() {
findCars() {
car {
id,
name,
model
}
}
}
인터페이스 사용의 장점
- 코드 재사용성: 공통 필드는 인터페이스에 정의되어 여러 유형 간에 공유되어 중복을 줄입니다.
- 단순화된 클라이언트 측 논리: 클라이언트는 객체 유형에 대해 조건부 확인이 필요하지 않습니다. 정확한 유형을 요청하고 응답을 확신하여 처리할 수 있습니다.
- 스키마 확장성: 새로운 공통 필드를 추가하는 것이 쉬워집니다. 인터페이스에만 정의하면 됩니다.
- 강제 구조: 인터페이스는 모든 구현 유형 간에 공유 구조를 강제하므로 일관성을 보장합니다(예: 모든 차량은
id,name,model을 가져야 함). - 통합된 쿼리: 서로 다른 유형을 개별적으로 쿼리하는 대신, 클라이언트는 모든 구현 유형에서 데이터를 검색하기 위해 단일 인터페이스를 쿼리할 수 있습니다.
- 개선된 문서화: 인터페이스를 통해 공통 동작을 정의함으로써 API 소비자가 관련 유형을 이해하고 작업하는 것이 더 쉬워집니다.
GraphQL Union
유니온은 GraphQL에서 클라이언트가 단일 필드를 통해 어떤 측면에서 관련된 여러 객체 유형을 쿼리할 수 있게 해주는 추상 유형입니다. 인터페이스와 달리 유니온은 구성원 유형이 공통 필드를 공유할 필요가 없습니다. 따라서 유니온은 관련 유형들이 서로 다른 구조를 가질 때 함께 쿼리할 필요가 있는 경우에 이상적입니다.
type Query {
getPurchaseItems(): [PurchaseItem!]!
}
union PurchaseItem = Product | Service | Subscription
type Product {
id: ID!
productName: String!
price: Float!
}
type Service {
id: ID!
serviceName: String
duration: Float
}
type Subscription {
id: ID!
planName: String
billingCycle: String
}
GraphQL 클라이언트 쿼리:
query getPurchaseItems() {
getPurchaseItems() {
purchaseItems {
... on Product {
id
productName
price
}
... on Service {
id
serviceName
duration
}
... on Subscription {
id
planName
billingCycle
}
}
}
}
이 예제에서 Product, Service, Subscription은 모두 PurchaseItem 유니온에 속하는 서로 다른 유형입니다. 클라이언트는 이 세 가지 유형을 단일 쿼리에서 프래그먼트를 사용하여 쿼리할 수 있으며, 이들은 어떤 필드도 공유하지 않습니다.
유니온에 대한 중요한 점은 유니온 유형의 구성원 유형은 모두 객체 기반 유형이어야 하며, 스칼라, 인터페이스 및 유니온 유형은 유니온의 구성원 유형이 되어서는 안 됩니다. 마찬가지로 래핑 유형도 유니온의 구성원 유형이 되어서는 안 됩니다.
유니온 사용의 장점
- 유연한 그룹화: 유니온은 공통 필드가 없는 관련 유형을 쿼리할 수 있게 해주며, 그렇지 않으면 다루기 번거로운 경우입니다.
- 단순화된 오류 처리: 클라이언트는 특정 유형을 쿼리하기 위해 프래그먼트를 사용할 수 있어 클라이언트 측에서 복잡한 조건 논리가 필요하지 않습니다.
- 이질적인 데이터 처리: 단일 쿼리를 통해 여러 유형에서 데이터를 검색할 수 있어 다양한 데이터 구조를 간소화하여 처리할 수 있습니다.
- 에러 응답에 유용함: 유니온은 성공 응답과 에러 세부 정보를 단일 응답 유형으로 결합하고 싶을 때 특히 유용하여 클라이언트가 이를 효율적으로 처리할 수 있게 합니다.
요약
GraphQL 인터페이스와 유니온은 GraphQL 스키마를 구조화하는 강력한 방법을 제공하여 유연성을 높이고 클라이언트-서버 상호작용을 단순화합니다. 인터페이스는 유형 간에 공유 필드를 허용하여 코드 재사용성을 촉진하고 스키마 확장을 용이하게 합니다. 반면 유니온은 공통 필드 없이 서로 다른 유형을 함께 쿼리할 수 있는 방법을 제공합니다.
Source:
https://dzone.com/articles/a-beginners-guide-to-graphql-interfaces-and-unions