GraphQL에 오신 것을 환영합니다.

웹 앱 API 개발을 위한 GraphQL 을 요약한 내용입니다.

1.1 GraphQL 이란?

• API를 만들 때 사용할 수 있는 쿼리 언어 입니다.
• 쿼리에 대한 데이터를 받을 수 있는 런타임이기도 합니다.
• GraphQL 쿼리는 실제로 필요한 데이터만 받도록 작성할 수 있습니다.
• query { person(personID: 5) { name birthYear created } }
• GraphQL 은 선언형(declarative) 데이터 페칭(fetching) 언어라고 흔히 일컬어집니다.
  • 개바자는 '무슨' 데이터가 필요한지에대한 요구사항을 작성하면 되고 '어떻게' 가져올지는 신경 쓰지 않아도 됩니다.
• GraphQL 서버 라이브러리는 다양한 언어로 만들어져 있습니다.
  • C#, 클로저, 엘릭서, 얼랭, 고, 그루비, 자바, 자바스크립트, 닷넷, PHP, 파이썬, 루비

1.1.1 GraphQL 명세

• GraphQL은 클라이언트와 서버 간의 통신 명세(스펙)서 입니다.

1.1.2 GraphQL 설계 원칙

• GraphQL 서비스를 만들 때 고려해야 할 지침이 몇가지 있습니다.

위계적

• GraphQL 쿼리는 위계성을 띠고 있습니다. 필드 안에 다른 필드가 중첩 될 수 있으며, 쿼리와 그에 대한 반환 데이터는 형태가 서로 같습니다.

제품 중심적

• GraphQL은 클라이언트가 요구하는 데이터와 클라이언트가 지원하는 언어 및 런타임에 맞춰 동작합니다.

업격한 타입 제한

• GraphQL 서버는 GraphQL 타입 시스템을 사용합니다. 스키마의 데이터 포인트마다 특정 타입이 명시되며, 이를 기초로 유효성 검사를 받게 됩니다.

클라이언트 맞춤 쿼리

• GraphQL 서버는 클라이언트 쪽에서 받아서 사용할 수 있는 데이터를 제공합니다.

인트로스펙티브(instrospective)

• GraphQL 언어를 사용해 GraphQL 서버가 사용하는 타입 시스템에 대한 쿼리를 작성할 수 있습니다.

1.2 GraphQL의 탄생

<aside> 💡 2012년 페이스북 내부에서 자사의 네이티브 모바일 앱을 다시 만들어야겠다는 결정을 내려졌습니다. 페이스북은 RESTful 서버와 FQL(페이스북의 SQL) 사용중이였습니다. 성능이 별로 였고, 앱은 자주 충돌이 났습니다. 엔지니어들은 데이터를 클라이언트 애플리케션으로 전송하는 방식을 개선해야 한다는 사실을 깨발았습니다.

</aside>

• 2015년 7월 GraphQL 초벌 명세와 Graphql.js라는 자바스크립트 GraphQL 페퍼런스 서버를 공개 했습니다.
• 현재 페이스북 내부의 데이터 페칭은 거의 다 GraphQL을 통해 이루지고 있습니다.
• IBM, Intuit, 에어비앤비 같은 회사에서도 제품에 사용하고 있습니다.

1.3 데이터 전송의 역사

1.3.1 RPC

• 1960년에 RPC(Remote Procedure Call, 원격 프로시저 호출)가 발명되었습니다.
  • 원격 컴퓨터로 요청 메세지를 보내 무엇인가를 하도록 만듭니다.
  • 원격 컴퓨터는 클라이언트로 응답 메세지를 보냅니다.
• 클라이언트가 서버로 데이터 요청을 보내고, 서버는 응답을 돌려줍니다.

1.3.2 SOAP

• 1990년 후반에 마이크로소프트에서 SOAP(Simple Object Access Protocol, 단순 객체 접근 프로토콜)가 나왔습니다.
• SOAP은 XML을 사용해 메세지를 인코딩하고 HTTP를 사용해 전송합니다.
• SOAP에서는 타입 시스템도 사용하고 리소스 중심의 데이터 호출이라는 개념도 도입해 사용했습니다.
• SOAP를 사용하면 결과 값을 예측하기가 상당히 쉬우나, 구현하기가 꽤 복잡하기 때문에 사용 도중 좌절할 위험이 있습니다.

1.3.3 REST

• REST는 로이 필딩(Roy Fielding)이 2000년에 작성한 캘리포니아 어바인 대학 학위 논문에서 정의된 개념입니다.
• 이 논문에서는 사용자가 GET, PUT, POST, DELETE와 같은 행동을 수행하여 웹 리소스를 가지고 작업을 진행하는 리소스 중심의 아키텍처에 대한 내용이 담겨 있습니다.
• 리소스 네트워크는 가상 상태 머신(virtual state machine)이며 행동(GET, PUT, POST, DELETE)는 머신 내의 상태를 바꿉니다.
• RESTful 아키텍처에서 라우트는 정보를 나타내는 개념입니다.
  • 라우트를 통해 정보를 요청하면 그에 따라 응답이 다르게 오게 됩니다./api/sport/skiing
  • /api/city/Lisbon
  • /api/food/hot-dog
• REST를 사용하면 데이터 모델의 엔드포인트를 다양하게 만들 수 있고, 이전의 아키텍처보다 개발하기 쉽습니다.
• 초반에는 REST는 XML과 함께 사용됐습니다.
  • AJAX는 원래 '비동기 자바스크립트 그리고 XML(Asynchronous JavaScript And XML)'의 머리글자만 따서 만들어진 단어였습니다.
  • AJAX 요청에 대한 응답 데이터가 XML 형식이었기 때문입니다.
  • 이 때문에 웹개발자가 받는 고통은 가중되었습니다.
• 더글러스 크록포드(Douglas Crocford)가 JSON(자바스크립트 객체 표기법)을 만들고 표준화했습니다.
• JSON은 특정 언어에 구애받지 않으며, 다양한 언어에서 파싱하고 사용할 수 있도록 우아한 데이터 포멧을 가지고 있습니다.

1.4 REST의 단점

• GraphQL이 처음 공개된 날, 일부 사람들은 GraphQL이 REST의 자리를 차지하 ㄹ것이라며 칭송했습니다.

1.4.1 오버페칭

// 필요한 데이터 
{
	"name": "Luke Skywalker",
	"height": "172",
	"mass": "77"
}

// 받은 데이터 
{
	"name": "Luke Skywalker",
	"height": "172",
	"mass": "77",
	"hair_color": "blond",
	"skin_color": "fair",
	"films": [
		"<https://swapi.co/api/films/2>",
		"<https://swapi.co/api/films/2>",
		"<https://swapi.co/api/films/2>",
		"<https://swapi.co/api/films/2>"
	],
	"species": [],
	"vehicles": [],
	"createed": "2020-10-07",
	...
}

• 필요하지 않은 데이터를 너무 많이 받아 올 수 있습니다.
• 클라이언트가 필요한 데이터 포인트는 세 개 뿐인데, 많은 키가 있는 객체를 받아서 쓸모없는 정보가 네트워크로 전송되어 버렸습니다.
• GraphQL 에서 요청을 보냈을 때
  • 필요한 필드만 기재되어 있습니다.
  • 요청한 데이터만 들어 있습니다.

query {
	person(personID: 1) {
		name
		height
		mass
	}	
}

• REST API 요청보다 선언적인 방식입니다.
• 블필요한 데이터를 가져오지 않았음으로 응답 속도 역시 빨라질 여지가 있습니다.

1.4.2 언더페칭(underfetch)

• 이름, 신장, 몸무게뿐 아니라 이제는 Luke Skywalker가 등장한 모든 영화의 제목이 담긴 목록을 화면에 노출 해야합니다.
• https://swapi.co/api/peple/1 에 데이터를 요청하고 나서 추가 데이터를 또 요청해야 하는 상황이 되었습니다. 이를 언더페칭(underfetch) 되었다고 표현합니다.
• GraphQL을 사용하면 쿼리를 중첩으로 정의해 페치 한 번에 필요한 모든 데이터를 요청하여 이런 언더페칭 문제를 해결할 수 있습니다.

query{
	person(personID: 1) {
		name
		height
		mass
		filmConnection {
			films {
				title
			}
		}
	}
}

1.4.3 REST 엔드포인트 관리

• REST API에 대한 흔한 불만 하나는 유연성이 부족하다는 것입니다.
• 클라이언트에 변경 사항이 생기면 대개 엔드포인트를 새로 만들어야하는데, 이렇게 되면 엔드포인트 개수가 몇배로 빠르게 늘어납니다.
  • 규모가 큰 앱에서는 보통 HTTP 요청을 최소화하고자 커스텀 엔드포인트를 사용합니다.
  • /api/character-width-movie-title 같은 식의 엔드포인트가 여기저기서 나타나게 됩니다.
  • 새로운 엔드포인트를 만들려면 프론트엔드와 백엔드 팀이 서로 협력해야 하므로 계획과 의사소통에 들어가는 시간이 걸어지기 때문입니다.
• GraphQL을 사용하면 설계상 엔드포인트가 보통 하나로 끝나게 됩니다.
• 단일 엔드포인트가 게이트웨이로써 몇 가지 데이터 소스를 조율하는 역활을 하게 되고 데이터 체계 역시 손쉽게 관리됩니다.
• REST의 단점을 논할 때는 많은 조직이 GraphQL과 REST를 같이 사용하고 있다는 것에 유의해야합니다.
• GraphQL 엔드포인트를 만들어 REST 엔드포인트의 데이터를 가져오는 식의 작업 방식은 완벽하게 유효한 GraphQL 사용법입니다.
• GraphQL을 점진적으로 도입할 수 있는 훌륭한 전략이 될 수 있습니다.

1.5 실생활에서의 GraphQL

• GraphQL은 여러 회사에서 앱, 웹사이트, API를 효율적으로 개발하기 위해 사용하고 있습니다.
• Github는 공식 웹사이트에서 "REST API v3과 비교했을 때, GraphQL은 사용자가 정말로 필요한 데이터만 정의해 사용할 수 있다는 강력한 정점을 지니고 있다"고 의견을 밝혔습니다.
• 뉴욕타임즈,IBM, 트위터, 옐프(Yelp)등 다른 회사도 GraphQL을 신뢰하기 시작했습니다.
• GraphQL을 집중적으로 다루는 콘퍼런스가 적어도 세 개 이상 존재합니다.

1.5.1 GraphQL 클라이언트

• 몇 가지 선택은 강제로 하게끔 만드는 툴이 등장하였으니, 바로 GraphQL 클라이언트 입니다.
• GraphQL 클라이언트의 목적은 개발자가 빠르게 작업할 수 있는 환경을 만들어주고 애플리케이션의 성능과 효율성을 끌어올리는 것입니다.
• Relay와 아폴로(Apollo)가 업계의 선두 주자입니다.
• RelayReact 컴포넌트 사이의 교두보 역활을 하고, GraphQL 서버에서 데이터를 페칭하는 용도로 만들어졌습니다.
• 페이스북, 깃허브, 트위치 등에서 사용하고 있습니다.
• 페이스북이 만든 클라이언트로 React와 React native와 함께 사용할 수 있습니다.
• 아폴로모든 주요 프론트엔드 개발 플랫폼에서 사용할 수 있으며, 프레임워크에 종속되어 있지 않습니다.에어비앤비, CNBC, 뉴욕타임즈, 티켓마스터와 같은 회사에서 실제 제품에 사용하고 있습니다.
• GraphQL 서비스르 만들 때 도움되는 개발 툴, 백엔드 서비스 성능 향상 서비스 및 GraphQL API 성능 모니터링 툴을 제공합니다.
• Meteor 개발 그룹에서 만들었으며, 더 복합적인 GraphQL 툴 제공을 목표로 커뮤니티 주도의 프로젝트가 진행 중입니다.