새로운 내용을 공부할 때
새로운 내용의 공부를 시작할 때 용어의 정의를 이해하지 못하거나 정확하게 알지 못한다면 그 용어가 포함된 문장을 이해하지 못합니다.
작은 단어 하나가 내용을 이해하지 못하게 하기 때문에 용어를 정확하게 이해하는 것이 중요합니다.
TIL) GraphQL가 특별한 이유
📌 2025-02-18 TIL
1. 오늘의 학습 주제
- RESTful API 와 GraphQL의 차이
2. 학습 내용
RESTful API 정리
RESTful API는 직관적이고 쉬운 설계가 가능합니다. RESTful API를 보고 어떤 리소스에 대한 행위를 확인할 수 있습니다.
GET 요청시 리소스 식별자를 통해 개발자가 추가 개발없이 캐싱 기능을 활용하여 성능 최적화가 가능합니다.
많은 프레임 워크에서 기본적으로 지원하며 JSON 요청과 응답이 표준화되어있습니다.
모니터링 및 디버깅이 용이합니다. HTTP 표준을 따르기에 로깅 시스템, 모니터링 툴과의 연동이 쉽습니다.
트래픽이 많을 때 최적화(CDN 및 프록시 서버활용)이 가능합니다.
다만, 클라이언트 요구하는 정보가 아닌 불필요한 데이터를 조회하는 오버 페칭과 필요한 정보를 못 불러오는 언더 페칭이 발생할 수 있으며 이를 해결하기 위해 추가 RESTful API를 개발해야합니다. 여러 클라이언트의 요구사항을 충족하기 위해 비슷한 RESTful API를 여러개 만들 수 밖에 없습니다. 이 문제는 필드 값을 추가하여 일부 해결은 가능합니다.
추가적인 버전 관리와 약속된 API 결과를 반환하기에 유연성이 떨어집니다.
페이징이나 정렬, 필터링을 수작업으로 추가해야합니다.
GraphQL 정리
GraphQL은 다양한 클라이언트가 여러 요구사항을 충족할 수 있는 유연성을 가지고 있습니다. 언더 페칭과 오버 페칭으로 인해 불필요한 API를 만들지 않기 때문에 관리하기 편합니다. 그리고 구독 기능을 통해 실시간 통신을 간편하게 구현할 수 있다는 장점이 있습니다.
API를 하나만 사용하기에 버전관리를 하지 않아도 되며 한번의 요청으로 대량의 데이터를 가져올 수 있습니다.
다만, 모든 요청이 POST이기에 캐싱 기능을 구현하려면 개발자의 추가 로직을 작성해야합니다. 그리고 학습 곡선이 있으며 추가 라이브러리를 사용하여야합니다. 클라이언트가 필요한 필드에 따라 권한 설정을 필드 단위로 해야하는 단점이 있으며 직관적이지 않기에 어떤 요청인지 확인하려면 body를 확인해야합니다.
3. 핵심 트레이드 오프
비교 항목 | RESTful API | GraphQL |
---|---|---|
데이터 요청 방식 | 미리 정의된 응답(JSON) 반환 | 클라이언트가 필요한 데이터만 선택 |
오버패칭/언더패칭 | 발생 가능 | 해결 가능 |
API 엔드포인트 관리 | 여러 개 필요 (/users , /posts ) |
단일 엔드포인트 (/graphql ) |
캐싱 지원 | HTTP 캐싱(CDN, 프록시 서버) 활용 가능 | HTTP 캐싱 어려움, 별도 캐싱 로직 필요 |
성능 최적화 | GET 요청 기반 캐싱, CDN 활용 가능 |
캐싱 어렵고, 서버 부담 증가 가능 |
권한 관리 | 엔드포인트 단위 권한 관리 | 필드 단위 권한 관리 필요 |
BFF(Backend for Frontend) 구조 | 어려움 (각 클라이언트 맞춤 API 필요) | 하나의 API로 다양한 클라이언트 지원 가능 |
버전 관리 | /v1/ , /v2/ 같은 버전 관리 필요 |
API 버전 관리 필요 없음 |
초기 설정 및 학습 비용 | 간단하고 직관적 | 학습 곡선이 높고, 추가 라이브러리 필요 |
실시간 기능 | 기본적으로 지원하지 않음 | Subscriptions(WebSocket)으로 실시간 데이터 지원 가능 |
쿼리 최적화 | RESTful API에서 미리 최적화 가능 | N+1 문제 발생 가능 → 최적화 필요 |
트래픽 처리 | CDN, API Gateway 활용 가능 | 서버에서 직접 최적화 필요 |
사용 사례 | 단순 CRUD, 공공 API, 정형화된 데이터 제공 | 다중 데이터 요청, 유연한 API 설계 필요 |
제가 생각하는 RESTful API는 자판기라고 생각합니다.
약속된 요청 데이터를 전달하면 그에 맞는 결과를 반환하는 방식입니다.
유연성이 떨어지지만 처음 사용하는 사람이라도 직관적이기 때문에 이해하기 쉽고 관리하기 쉽습니다.
다만 추가적인 요구사항이 있을 경우에는 버튼이 점점 늘어나는 것처럼 API도 늘어납니다.
GraphQL은 안내데스크라고 생각합니다.
남녀노소 질문 방식이 달라지더라도 유연하게 대처할 수 있다는 장점이 있습니다.
다만, 유연하게 대처하기 까지 학습과 기계처럼 최적화를 하기 위해서는 추가적인 프로세스가 필요하게 됩니다.
그리고 유연하기 때문에 정보를 재사용 하려면 남녀노소 질문을 이해하는 시간이 필요한 것처럼 추가적인 로직이 필요합니다.
댓글남기기