GraphQL vs REST API

미뤄왔던 graphQL에 대해 알아보자.
"graphQL을 잘 사용하면 프론트엔드 개발자에게 response 수정 요청을 덜 받을 수 있지 않을까..?"

에서 출발하는 정리글이다!

1. GraphQL이란?

• GraphQL은 Facebook에서 만든 API 쿼리 언어이자 런타임 환경입니다.
• REST API처럼 여러 엔드포인트를 만드는 대신, 하나의 엔드포인트에서 필요한 데이터만 선택해서 가져올 수 있습니다.

2. REST API vs GraphQL

REST API의 한계

• Over-fetching: 필요한 데이터보다 많이 받아옴
• Under-fetching: 필요한 데이터를 얻기 위해 여러 번 요청 필요

GraphQL의 해결 방식

• 필드 단위로 필요한 데이터만 요청 가능 → Over-fetching 해결
• 여러 리소스를 한 번에 조회 가능 → Under-fetching 해결

---

3. GraphQL 동작 방식

• Query: 데이터 조회 (REST GET 역할)
• Mutation: 데이터 변경(생성, 수정, 삭제) (REST POST/PUT/DELETE 역할)
• 단일 엔드포인트: 대부분 /graphql 하나로 처리

---

4. GraphQL 장점

1. 필요한 데이터만 요청 가능 → 네트워크 비용 절감
2. 한 번의 요청으로 여러 리소스 조회 가능
3. 스키마 기반 API → 어떤 데이터가 제공되는지 명확
4. 프론트엔드 개발 효율 증가 → 백엔드 수정 없이 UI 맞춤형 데이터 요청 가능

---

5. GraphQL 단점

1. 복잡한 쿼리 최적화 필요 → N+1 문제 주의
2. 캐싱 어려움 → REST처럼 URL 단위 캐싱 불가
3. 학습 비용 존재 → REST에 익숙한 개발자에게 러닝 커브
4. 프론트엔드가 데이터 구조를 알게 될 수 있음
   • 클라이언트가 스키마 기반으로 요청을 직접 작성 → DB 구조를 노출하는 듯한 설계가 될 수 있음

Q: 프론트엔드가 디비를 알아야 한다는 단점도 있네?

• 해결 방법: DB 모델을 그대로 노출하지 않고 비즈니스 도메인 단위로 추상화

# 나쁜 예시 (DB 구조 그대로 노출)
type User {
  id: ID!
  name: String
  password: String
  orders: [Order]
}

# 좋은 예시 (비즈니스 단위 추상화)
type UserProfile {
  id: ID!
  displayName: String
  orderHistory: [OrderSummary]
}

6. GraphQL vs REST 사용 판단 기준

GraphQL을 써야 할 때

•	클라이언트마다 필요한 데이터가 다를 때
•	여러 리소스를 한 번에 조회해야 할 때
•	스키마 기반 계약(API 명세) 관리가 필요할 때
•	관계형 데이터 조회가 많을 때
•	여러 클라이언트에서 동일 API를 다양하게 소비할 때

REST로 충분할 때

•	API 단순 CRUD 위주일 때
•	성능/캐싱 최적화가 중요한 경우
•	내부 시스템 통신 등 정해진 데이터만 주고받을 때
•	팀에서 GraphQL 경험이 적고 학습/운영 비용이 부담될 때

RestApi 처럼 GraphQL도 형식이다.

Spring Boot에서는 spring-boot-starter-graphql로 쉽게 GraphQL 서버 구성 가능

기타 GraphQL 솔루션

다양한 라이브러리와 도구는 공식 사이트에서 확인 가능
https://graphql.org/community/tools-and-libraries/?tags=

---

참고: 얄팍한 GraphQL과 Apollo https://inf.run/YH988