GraphQL
Graph Query Lanuqge
서버로부터 데이터를 효율적으로 가져오기 위해
서버와 엡 클라이언트간의 질의어 sql은 서버와 db간의 질의어
주체 : 웹클라이언트
< ENDPOINT >
다중 엔드포인트, URL과 METHOD에 따라 접근할수 있는 데이터가 다르다
/posts /comments /authors
vs
/graphql 이라는 하나의 ENDPOINT로 요청
보통 단일 엔드포인트, GraphQL스키마(데이터의 구조, 규격화, 질의 내용)에 따라 데이터가 다르다.
<리소스>
REST =-API
리소스 모양과 크기는 서버에 의해서 결정된다.
-api가어떤 데이터와 크기를 내려줄지 프론트는 모른다.
-프론트입장에서 수동적
VS
GraphQL
클라이언트가 필요한 리소스를 요청한다.
-질의 주체가 클라이언트가이기때문에 리소스를 요청
-프론트입장에서 주도적
<라우트 핸들러와 리졸버>
각 요청은 정확히 하나의 경로 처리 함수를 호출
vs
하나의 쿼리가 여러 리졸버를 호출하여 여러 리소스가 포함된 중첩 응답
구성
연계된거까지 중첩해서 응답을 구상해서 준다.
graphql 이 rest api보다 나은점.
사용자/게시물/ 팔로워데이터를 받아오려면 3가지를 요청해야한다.
/users/
/users//posts
/users//follwers
즉 , rest api를 사용하면 일반적으로 여러 엔드포인트에 엑세스해서 데이터를 수집해야한다.
graphql은 이 3가지를 담은 스키마를 요청하면 한번에 받아온다.
구처적인 데이터 요구사항이 포함된 단일 쿼리로 요청가능하다.
사용자/게시물/팔로워 데이터를 받아오려면
query {
User(id: "er3tg439frjw"){
name
posts {title}
followers {name}
}
}
RestAPi는 overfetching과 underfetching을 유발시킨다.
overfetching
사용자 이름만 알고 싶은데, /users/ 호출하면 서버가 정해둔 모든 데이터를 받아오게 된다.
underfetching
사용자 졍보랑 팔로워 알고 싶은데,
/users/ 호출하고
/users//followers호출해야 한다.
QraphQL은 overfetching, underfetching x
필요한 데이터만 요청할 수 있다.
원하는 중첩 데이터 요청을 할 수 있다.
그외의 장점
프론트엔드에서 신속한 제품 이터레이션을 돌릴 수 있다.
(서버에 매번 API 요청을 하지 않아도됨)
백엔드에서 분석이 가능하다.
(프론트엔드에서 어던 데이터를 가져다 쓰는지 알게 되므로)
스키마 및 타입 시스템의 이점이 있다.
(프론트엔드와 백엔드가 사용하는 데이터 구조를 맞출 수 있음.)
