GraphQL이란
GraphQL은 API를 위한 쿼리 언어이며 이미 존재하는 데이터로 쿼리를 수행하기 위한 런타입이다.
여기서 쿼리란 DB에서 특정한 데이터를 효율적으로 가져오기 위한 사용자의 요청이다.
GraphQL - Graph Query Language
웹 클라이언트가 서버로부터 데이터를 효율적으로 가져오기 위해
GraphQL vs REST API
- Resource 부분
- GraphQL: 클라이언트가 필요한 리소스를 요청한다.
- 쿼리의 주체가 웹 클라이언트(프론트)이기 때문에 프론트가 주도권을 가진다.
- REST API: 리소스 모양과 크기는 서버에 의해 결정된다.
- API 요청시 그 API가 어떤 데이터를 내려줄지 프론트에서는 모른다. 서버가 주도권을 가진다.
- End-Point 부분
- GraphQL: 보통 단일 엔드포인트, GraphQL 스키마에 따라 데이터가 다르다.
- 스키마를 통해 요청하는 데이터, 데이터가 어떤 구조를 가지고 있는가를 미리 알 수 있다.
- REST API: 다중 엔드포인트, URL과 Method에 따라 접근할 수 있는 데이터가 다르다.
- Route Handler & resolver 부분
- GraphQL: 하나의 쿼리가 여러 resolver를 호출하여 여러 리소스가 포함된 중첩 응답 구성
- 같은 엔드포인트로 결과가 A,B 둘다 보여줄 수 있고 A와 B를 합쳐 만든 결과를 보여줄 수도 있다.
- REST API: 각 요청은 정확히 하나의 경로 처리 함수를 호출
- 하나의 엔드포인트에는 하나의 처리만 된다.
*resolver: DNS의 클라이언트
역할: 호스트 정보를 구하는 프로그램의 요청을 네임 서버에 대한 질의 형태로 번역하고, 질의에 대한 응답을 프로그램에 적절한 형태로 변경하는 일
- GraphQL이 더 좋은 이유
- REST API
1. REST API를 사용하면 여러 엔드포인트에 접근해서 데이터를 수집해야한다. ```
사용자, 게시물, 팔로워 데이터를 받아오려면
/users/<id>
/users/<id>/posts
/users/<id>/followers
```
2. REST API는 overfetching과 underfetching을 유발 시킨다.
- 사용자 이름만 알고싶은데, /users/를 호출하면 서버가 정해둔 모든 데이터를 받아오게 된다. (overfetching: 불필요한 데이터까지 가져오는 것)
- 사용자 정보랑 팔로워를 한 번에 알고 싶으면 /users/를 호출하고 /users//followers도 호출해야한다.
(underfetching: 원하는 데이터가 2개인데 각 api가 하나씩 존재해서 두 api를 조합해서 써야하는 경우)
- GraphQL
[1] GraphQL은 구체적인 데이터 요구 사항이 포함된 단일 쿼리로 요청 가능하다.사용자, 게시물, 팔로워 데이터를 받아오려면
query {
User(id:"id값..."){
name
post {title}
followers {name}
}
}
[2] GraphQL은 overfetching X, underfetching X
- 필요한 데이터만 요청
- 원하는 중첩 데이터를 요청할 수 있다.
[3] FE에서 신속한 제품 이터레이션을 돌릴 수 있다.(서버에 매번 API 요청을 하지 않아도 됨)
[4] 백엔드에서 분석이 가능하다 (FE에서 어떤 데이터를 가져다 쓰는지 알 수 있어서)
[5] 스키마 및 타입 시스템의 장점이 있다. (FE와 BE가 사용하는 데이터 구조를 맞출 수 있다.)
GraphQL 사용 이유
- 같은 DB로 다양한 UI를 구상할 필요가 있다.
- 같은 화면이여도 모바일, PC, 테블릿 등 화명 크기에 따라 다른 UI로 화면을 구성해야함
- 게시글 데이터가 상황마다 다르다
정리 비교
GraphQL 나오기 전 | GraphQL 나온 후 |
---|
SQL: 서버와 DB 간의 질의어 | Server와 Web Client 간의 질의어 |
REST API 문제 | 다중 엔드포인트 -> 단일 엔드포인트 |
OverFetching 문제 | 필요한 데이터만 요청 |
UnderFetching 문제 | 한번의 요청으로 다양한 데이터 받음 |