2. GraphQL is the better REST

GraphQL은 더 좋아진 REST

REST 웹 API를 설계하는 표준으로 거듭(표준이라고 명칭을 내리기에는 애매하지만 다수 사용)

REST는 무상태 서버, 자원에 대한 구조화된 접근과 같은 훌륭한 발상을 제공합니다.

REST API는 오늘 날 클라이언트의 급변하는 요구 사항들을 만족시키기에는 유연성이 부족합니다.

GraphQL은 이러한 유연성과 효율성을 향상시키고자 하는 요구에 부합하고자 개발되었다.

GraphQL을 사용하면 개발자들이 REST API와 상호작용할 때 경험했던 단점과 비효율을 해결할 수 있습니다.

REST API 예

여러 개의 엔드포인트로부터 데이터를 모으는 것이 일반적이다. 우선 해당 사용자의 데이터를 /user/:id 엔드포인트를 통하여 불러올 수 있습니다. 다음으로, 해당 사용자의 모든 게시글을 불러오는 데에 /user/:id/posts 엔드포인트를 사용할 수 있습니다.

/user/:id/followers 를 사용하여 사용자의 팔로워 명단을 불러올 수 있습니다.

단점: REST를 사용하면 데이터를 불러오기 위하여 각각의 엔드포인트들에 3번의 요청을 보내야 합니다. 게다가 필요없는 정보깍지 가져오게 됨으로써 데이터를 과하게 불러오게 됩니다.

GraphQL 예

구체적인 데이터 요구사항을 포험한 딱 하나의 쿼리를 GraphQL 서버에 보내게 됩니다. 그러면 서버는 요구사항에 일치하는 JSON 객체를 반환해줍니다.

// graphql
query {
	User(id: “1234567”) {
		name
		posts {
			title
		}
		followers(last: 3) {
			name
		}

{
	“data”: {
		“User”: {
			“posts”: [
				{“title”: “안녕하세요”}
			],
			“followers”: [
				{“name”: “신은지”},
				{“name”: “신은지”},
				{“name”: “신은지”},
			]
		}
	}
}

클라이언트에게 필요한 데이터를 쿼리에 정확히 특정해줄 수 있으며, 서버로부터 반환된 데이터의 구조가 쿼리에 정의도니 중첩 구조를 정확히 따르고 있다는 점.

데이터를 딱 필요한 만큼만 불러오세요

REST가 가지는 가장 흔한 문제 중 하나가 바로 데이터를 더 가져오거나(Overfetch), 덜 가져오는(Underfetch) 문제

이러 일이 발생하는 이유는 클라이언트가 데이터를 다운받는 유일한 방법이 바로 고정된 데이터 구조를 반환하는 에드포인트에 요청하기 때문입니다.

클라이언트가 필요로 하는 데이터를 정확히 제공하도록 API를 설계하는 것은 아주 어렵습니다.

Overfetch: 데이터를 너무 많이 불러오기

overfetch란 어플리케이션에서 실제로 필요한 것보다 더 많은 정보를 클라이언트가 다운받는 것을 말한다.

각 사용자의 이름만 필요한 상황에서 REST API처럼 모든 데이터를 다 가져오는게 아닌 GraphQL은 필요한 데이터만 가져옵니다.

(user: {name}}만 가져오면 됨. => Address, Age, Birth 까지 가져올 필요 X

Underfetch와 n+1 문제

특정 엔드포인트가 필요한 정보를 충분히 제공하지 못하는 경우.

클라이언트는 필요한 정보를 모두 확보하기 위하여 추가적인 요청을 보내야만 합니다. 그러면 리스트를 불러온 뒤, 리스트 내 각각의 요소들에 대하여 한번씩 더 추가적으로 요청을 보내야 하는 사오항이 되버림.

API /user/:id/followers 엔드포인트를 추가하는 상황에서 /user엔드포인트에 요청을 보내고 각각 엔드포인트 요청을 보내야합니다.

프론트엔드의 빠른 개발 순환 (Iteration)

REST API의 흔한 패턴은 어플리케이션의 화면(View) 관점에서 엔드포인트를 구조화하는 것입니다

클라이언트의 특정 화면에서 필요한 정보를 얻으려면 대응하는 엔드포인트에 접근하기만 하면 되므로 아주 편리합니다.

이 접근의 가장 큰 단점은 프론트엔드 개발이 빠르게 순환하기 어렵게 만든다는 것 입니다. UI를 조금이라도 바꾸면, 필요한 데이터가 변할 수 있기 때문에 필요한 데이터가 달라지면 백엔드는 이에 대응하여야 합니다. 이로 인하여 생산성이 떨어지고, 사용자 피드백을 제품에 통합하는 것이 느려집니다.

GraphQL을 사용하면 이러한 문제가 해결됩니다.

GrpahQL의 유연한 특성 덕분에 서버에서 추가로 작업하지 않더라도 클라이언트를 수정할 수 있습니다.

클라이언트가 데이터 요구 사항을 정확하게 특정할 수 있으므로, 프론트엔드의 디자인 또는 필요 데이터가 변하더라도 백엔드 엔지니어가 일하지 않아도 됩니다.

백엔드에 대한 통찰력 있는 분석

GraphQL를 사용하면 백엔드에 요청된 데이터에 대하여 세밀하게 분석할 수 있습니다. 각 클라이언트는 관심있는 정보만을 정확히 특정하므로, 사용가능한 데이터들이 어디서 어떻게 사용되는지 심도있게 이해할 수 있습니다.

특정 API를 업그레이드시키거나, 클라이언트들이 더 이상 사용하지 않는 필드를 Deprecate하는 식으로 활용할 수 있습니다.

GraphQL을 사용하면, 서버가 처리하는 요청들에 대하여 저수준의 성능 모니터링이 가능하며, GraphQL은 resolver 함수라는 개념을 사용하여 클라이언트가 요청한 데이터를 수집합니다. resolver를 사용하여 성능을 측정하면 시스템의 병목에 대한 중요한 통찰을 얻을 수 있습니다.

Schema 와 Tyle 시스템의 이점

GraphQl은 API의 기능을 정의할 떄 강타입 체계를 사용합니다. API로 노출되는 모든 타입들은 GraphQL스키마 정의 언어로 자가성된 스키마에 정의됩니다.

이 스키마는 마치 클라이언트와 서버 간의 계약과 같이 작용하여, 클라이언트가 데이터를 접근하는 방법을 정의합니다.

스키마가 정의되면 프론트엔드와 백엔드는 추가적인 의사소통을 하지 않고 각자의 업무에 전념할 수 있습니다.

양측 모두, 네트워크 상에서 전달된 확실한 데이터 구조를 인지하는 상황이기 때문입니다.

프론트엔드는 필요한 데이터 구조를 모킹하는 것으로 간단하게 어플리케이션을 테스트할 수 있습니다. 서버가 준비되고나면, 실제 API를 사용하여 클라이언트 어플리케이션에 데이터를 제공하면 됩니다.