GraphQL

2022.05.19

1. GraphQL 소개

	REST API	GraphQL
리소스	리소스 모양과 크기기는 서버에 의해 결정	클라이언트가 필요한 리소스를 요청
엔드포인트	다중엔드포인트, URL과 Method에 따라 접근할 수 있는 데이터가 다르다.	보통 단일 엔드 포인트, GraphQL 스키마에 따라 데이터가 다르다.
라우트 핸들러와 리졸버	각 요청은 정확히 하나의 경로 처리 함수를 호출	하나의 쿼리가 여러 리졸버를 호출하여 여러 리소스가 포함된 중첩 응답 구성

https://www.howtographql.com/basics/1-graphql-is-the-better-rest/
REST API를 사용하면 일반적으로 여러 엔드포인트에 엑세스해서 데이터를 수집해야한다.

사용자     게시물             팔로우 데이터를 받아오려면 
/user/<id> /user/<id>/posts  /user/<id>/followers

GraphQL은 구체적인 데이터 요구 사항이 포함된 단일 쿼리로 요청 가능

사용자     게시물             팔로우 데이터를 받아오려면 
query{
  User(id: "asdf") {
    name
    posts{title}
    followers{name}
  }
}

REST API는 overfetching과 ubderfetching을 유발시킨다.
사용지 이름만 알고 싶은 데, /user/<id> 호출하면 서버가 정해둔 모든 데이터를 
받아오게 된다.


사용자 정보랑 팔로워 알고 싶은 데  /user/<id> 호출하고 /user/<id>/followers 
호출해야 한다.

GraphQL은 overfetching X , ubderfetching X
필요한 데이터만 요청할 수 있다.
원하는 중첩 데이터 요청을 할 수 있다.

프론트엔드에서 신속한 제품 이터레아션을 돌릴 수 있다.
(서버에 매번 API 요청을 하지 않아도 됨)

백엔드에서 분석이 가능하다.
(프론트엔드에서 어떤 데이터를 가져다 쓰는 지 알 수 있게 되므로)

스키마 및 타입 시스템의 이점이 있다.
(프론트엔드와 백엔드가 사용하는 데이터 구조를 맞출 수 있음)

Facebook에서 GraphQL 만든 이유

같은 DB로 다양한 UI를 구상할 필요가 있었음
Facebook의 같은 홈 화면이어도, 모바일 웹 / 모바일 앱(IOS, Android) / PC 웹 경우 각각 다른 UI로 화면을 구성할 필요가 있었음

게시글에 대해서도 보여주는 데이터가 제각각
이런 상황을 해소하기 위해 기존의 REST API 방식과 다른 접근을 한듯

GraphQL 소개

vs SQL --> Server 와 Web Client 간의 질의어
vs REST API --> 다중 엔드포인트 => 단일 엔드포인트
Overfetching --> 필요한 데이터만 요청
Ubderfetching --> 한번의 요청으로