GraphQL.. 그래프?.. 뭐시기?..

때는 이번 년 초, 처음 graphQL을 접했었는데 이때 사실 REST API라는 것도 몰랐고 API라는 것의 뜻도 몰랐을 때였다.

그래서 아무것도 모른 채 무지성으로 막 했었던 기억이 있는데 지금의 나는 그때와 다르지 ㅋ.
난 지금 존내 어썸하니까 ㅋ

자 그래서 이번에는 GraphQL을 알아보려고 한다. 그러기에 앞서서 공식문서를 잠시 보고 가자.

GraphQL은 API를 위한 쿼리 언어이며 이미 존재하는 데이터로 쿼리를 수행하기 위한 런타임 입니다. 
GraphQL은 API에 있는 데이터에 대한 완벽하고 이해하기 쉬운 설명을 제공하고 
클라이언트에게 필요한 것을 정확하게 요청할 수 있는 기능을 제공하며 
시간이 지남에 따라 API를 쉽게 진화시키고 강력한 개발자 도구를 지원합니다.

Zzzz..

어어 다 읽었니?

사실 이 의미는 크게 이해할 필요는 없고 REST API의 차이점과 대조만 하면 쉽게 이해된다.

REST API를 구축해봤으면 불편한게 있을 거다.

그건 바로

라우트 구조를 조오오온나게 짜야하는 거다. 사실 REST API는 url만 보고 무슨 자원인지 가져올 수 있는 직관적이라는 것이 장점이라고 생각함. 근데 그래도 넘 귀찮고 생각해야 하며 어쩌고 저쩌고의 단점들이 많다. 그냥 단순하게 가져오고 싶은 걸 SQL 쿼리 마냥 써서 보낼 순 없나?
해서 나온게 GraphQL의 목적이라고 본다.

아니 그래서 어떻게 쓰냐고오오오오오

라는 생각을 하는 사람들을 위해 아주 간단한 예제를 보여주겠다.

만약에

{
	"name": "jayden",
    	"family": {
        	"count": 4,
            	"location": "changwon"
         }
}

뭐 이 데이터를 가져와야 한다면 REST API 에서는 아마

GET /users/1

이런 식으로 가져올 것이다. 물론 지금 이건 간단한 예제라서 이렇게 하면 되지. 말 겁나 많네.
아 라고 생각할 수 있지만 조금만 해보면 여간 귀찮은 게 아님. 그래서 GQ를 이용해서

type User {
	id: ID,
	name: String,
    	family: Family
}

type Family {
	id: ID
	count: Number,
        location: String
}

type Query {
	user(id: ID): User,
        family(id: ID): Family
}

뭐 이런 식으로 된다. 완전 개코드였긴 하지만 딱 대충보면 다르지 않나?
이거를 이제 Schema라는 개념을 이용해서 리소스를 요청하게 된다.

GQ는 딱 두 가지로 Schema 타입이 있는데 Query와 Mutation이다.

Query는 REST에서 GET과 같은 역할을 하고 Mutation은 나머지 CUD와 같은 역할을 한다.

또한 GQ는 엔드포인트가 딱 하나이기 때문에 이러한 Query를 서버에서 요청으로 받게 되면 각 필드(저기 보면 이름이나 family에 해당하는 것)의 데이터 응답 처리 함수를 실행해야 하는데 그것의 역할을 맡은 놈을 보고 Resolver라고 함.

사실 내가 마음이 급하기도 하고 글솜씨가 다시 보니까 개판이라서 좀 더 정돈된 아티클을 발견했는데 여기에 링크를 걸어두겠음.

어쨌든 GQ는 결국 URL 기준으로 리소를 가져오는 것이 아니라 진짜 필요한 리소스를 바로 쿼리로 날리기 때문에 오버페칭이나 언더페칭의 문제가 없다는 장점도 있다.

결론: GraphQL 좋음. 한번 이걸 이용해서 웹 백엔드 구축해보는 경험도 나쁘지 않음