REST API의 한계와 GraphQL

GraphQL이 등장하기 전 - REST API란?

소프트웨어 간 소통

: 리소스(URI) + 요청 방식(GET/POST/PUT&PATCH/DELETE)

 

• get : 요청
• post: 추가
• put: 수정
• delete: 삭제

 

---

REST API 한계

REST API의 2가지 핵심 문제
├── 🔴 Overfetching (너무 많이 가져오기)
│   ├── 고정된 응답 구조
│   ├── 불필요한 데이터 전송
│   └── 모바일/성능 문제
└── 🔵 Underfetching (충분히 못 가져오기)
    ├── 여러 번의 API 호출
    ├── N+1 문제
    └── 네트워크 지연 누적

---

Overfetching 

핵심 개념

• 고정된 응답: REST API는 항상 같은 형태로 응답
• 데이터 낭비: 필요한 것보다 많은 정보 전송
• 모바일 킬러: 데이터 요금제와 배터리 소모의 주범

실생활 비유

🏪 마트에서 우유만 사러 갔는데
📦 우유+빵+과자+생선이 세트로만 판매
💸 결국 불필요한 것까지 다 사야 함

코드로 보는 문제

// 필요한 것: 이름만
{ name: "김철수" }

// 실제 받는 것: 모든 정보
{
  name: "김철수",
  email: "kim@example.com",
  address: "서울시 강남구...",
  phone: "010-1234-5678",
  // ... 20개 이상의 불필요한 필드
}

주요 피해

• 💰 데이터 비용: 모바일 요금제 빠른 소모
• 🔋 배터리: 더 많은 데이터 처리로 배터리 드레인
• ⏱️ 속도: 큰 파일 다운로드로 느린 로딩

---

Underfetching 

핵심 개념

• 조각난 데이터: 필요한 정보가 여러 API에 분산
• N+1 문제: 1개 조회 후 N개 추가 조회 필요
• 지연 누적: 여러 요청의 대기시간이 합쳐짐

실생활 비유

🍕 피자 주문하려면
📞 1. 피자집에 전화 (메뉴 확인)
📞 2. 토핑 가게에 전화 (토핑 종류)
📞 3. 음료 가게에 전화 (음료 선택)
📞 4. 배달업체에 전화 (배달 시간)
⏰ 총 4번의 전화로 시간 오래 걸림

코드로 보는 문제

// 블로그 포스트 하나 보려면...
const post = await fetch('/posts/123');        // 1번째
const author = await fetch('/users/456');      // 2번째  
const comments = await fetch('/posts/123/comments'); // 3번째
// 댓글 작성자들 정보까지... 총 5-10번 요청!

주요 피해

• ⏳ 로딩 지연: 여러 요청 대기시간 누적
• 📱 모바일 악몽: 3G에서 1초 * 5번 = 5초 대기
• 🐛 복잡성: 에러 처리, 상태 관리 복잡

---

REST의 구조적 한계

• 📋 고정 스키마: 서버가 정한 형태로만 응답
• 🔗 리소스 분리: 관련 데이터가 다른 URL에 분산
• 🚫 유연성 부족: 클라이언트 요구사항 반영 어려움

설계 철학의 문제

• 서버 중심: 서버 편의에 맞춘 설계
• 일률적 응답: 모든 클라이언트에게 동일한 데이터
• 정적 구조: 런타임에 데이터 구조 변경 불가

---

 

해결책 

GraphQL 방식

query {
  user(id: 123) {
    name          # 필요한 것만
    email         # 선택해서
    posts {       # 한 번에
      title       # 가져오기
    }
  }
}

REST 개선 방법

• 필드 선택: ?fields=name,email
• 데이터 포함: ?include=posts,comments
• 배치 요청: 여러 요청을 하나로 묶기
• 캐싱: 중복 요청 줄이기

---

 

 핵심 3가지

1️⃣ Overfetching = "필요한 것보다 많이" = 성능 문제
2️⃣ Underfetching = "여러 번 요청해야" = 지연 문제  
3️⃣ 해결책 = GraphQL 또는 REST 개선 기법