Facebook이 만든 쿼리 언어
서버로부터 데이터를 효율적으로 가져오기 위해
주체:웹클라이언트
Rest Api
리소스 모양과 크기는 서버에 의해 결정된다
GraphQL
클라이언트가 필요한 리소스를 요청 한다.
엔드포인트
라우터 핸들러와 리졸버
Rest Api
각 요청은 정확히 하나의 경로 처리 함수를 호출
GraphQL
하나의 쿼리가 여러 리졸버를 호출하여 여러 리소스가 포함된 중첩 응답구성
요청하는 쪽에서 원하는 것을 요청할 수 있다. 같은 엔드 포인트를 요청하면 내가 원하는 요청방식을 보여주면서도 중첩하면서까지 보여준다.
Rest Api를 사용하면 일반적으로 여러 엔드포인트에 엑세스해서 데이터를 수집
사용자/ 게시물/팔로워 데이터를 받아오려면
/users/<id>
/users/<id>/posts
/users/<id>/followers
GraphQL은 구체적인 데이터 요구 사항이 포함된 단일 쿼리로 요청가능
사용자 / 게시물 / 팔로워 데이터를 받아오려면
query{
User(id:"eee344"){
name
posts{title}
followers{name}
}
}
Rest API는 overfetching과 underfetching을 유발시킨다.
overfetching은 내가 원하는 데이터만 가져와서 사용하고 싶은데 모든 데이터를 가져와서 개발자가 분류 하여 사용하여야 한다.
사용자 이름만 알고 싶은데,
/users/ 호출하면 서버가 정해둔 모든 데이터를 받아오게 된다.
사용자 정보랑 팔로워 알고 싶은데
/users/호출하고
/users//followers호출해야 함.
GraphQL은 overfetching X, underfetching X
필요한 데이터만 요청함.
원하는 중첩 데이터 요청을 할 수 있다.
프론트엔드에서 신속한 제품 이터레이션을 돌릴 수 있다.
(서버에서 매번 API 요청을 하지 않아도 됨)
백엔드에서 분석이 가능하다.
(포론트엔드에서 어떤 데이터를 가져다 쓰는지 알수 있게 되므로)
스키마 및 타입 시스템의 이점이 있다.
(프론트엔드와 백엔드가 사용하는 데이터 구조를 맞출 수 있음)
같은 DB로 다양한 UI를 구상할 필요가 있었다.
facebook의 같은 홈 화면이라도 모바일 웹/ 모바일 앱/PC 웹
경우 각각 다른 UI로 화면을 구성할 필요가 있었음
게시글에 대해서도 보여주는 데이터가 제각각
이런 상황을 해소하기 위해 기존의 REST API 방식과 다른 접근을 한듯