[GraphQL 튜토리얼]
https://www.howtographql.com/graphql-js/1-getting-started/
[Scalar Types]
https://graphql.org/learn/schema/#scalar-types
[Non-Null List of Strings]
https://graphql.org/learn/schema/#lists-and-non-null
[GraphQL Server Basics: GraphQL Schemas, TypeDefs & Resolvers Explained]
https://www.prisma.io/blog/graphql-server-basics-the-schema-ac5e2950214e
[GraphQL SDL - Schema Definition Language]
https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51
[카카오 기술문서]
https://tech.kakao.com/2019/08/01/graphql-basic/
"gql에는 쿼리에 변수라는 개념이 있는데, 이 개념은 이러한 용처를 위해 존재 하는것 입니다. gql을 구현한 클라이언트에서는 이 변수에 프로그래밍으로 값을 할당 할 수 있는 함수 인터페이스가 존재합니다. react apollo client의 경우에는 variables 라는 파라메터에 원하는 값을 넣어주면 됩니다."
오퍼레이션 네임 쿼리는 매우 편리 합니다.
굳이 비유하자면 쿼리용 함수 입니다.
데이터베이스에서의 프로시져(procedure) 개념과 유사하다고 생각하면 됩니다.
이 개념 덕분에 여러분은 REST API를 호출할때와 다르게,
한번의 인터넷 네트워크 왕복으로 여러분이 원하는 모든 데이터를 가져 올 수 있습니다. 데이터베이스의 프로시져는 DBA 혹은 백앤드프로그래머가 작성하고 관리 하였지만, gql 오퍼레이션 네임 쿼리는 클라이언트 프로그래머가 작성하고 관리 합니다.
리졸버(resolver)
데이터베이스 사용시, 데이터를 가져오기 위해서 sql을 작성 했습니다.
또한, 데이터베이스에는 데이터베이스 어플리케이션을 사용하여 데이터를 가져오는 구체적인 과정이 구현 되어 있습니다.
그러나 gql 에서는 데이터를 가져오는 구체적인 과정을 직접 구현 해야 합니다.
gql 쿼리문 파싱은 대부분의 gql 라이브러리에서 처리를 하지만,
gql에서 데이터를 가져오는 구체적인 과정은 resolver(이하 리졸버)가 담당하고,
이를 직접 구현 해야 합니다.
프로그래머는 리졸버를 직접 구현해야하는 부담은 있지만,
이를 통해서 데이터 source의 종류에 상관 없이 구현이 가능 합니다.
예를 들어서,
리졸버를 통해 데이터를 데이터베이스에서 가져 올 수 있고,
일반 파일에서 가져 올 수 있고,
심지어 http, SOAP와 같은 네트워크 프로토콜을 활용해서 원격 데이터를 가져올 수 있 습니다.
덧붙이면, 이러한 특성을 이용하면 legacy 시스템을 gql 기반으로 바꾸는데 활용 할 수 있습니다.
gql 쿼리에서는 각각의 필드마다 함수가 하나씩 존재 한다고 생각하면 됩니다.
이 함수는 다음 타입을 반환합니다.
이러한 각각의 함수를 리졸버(resolver)라고 합니다.
만약 필드가 스칼라 값(문자열이나 숫자와 같은 primitive 타입)인 경우에는 실행이 종료됩니다. 즉 더 이상의 연쇄적인 리졸버 호출이 일어나지 않습니다.
하지만 필드의 타입이 스칼라 타입이 아닌 우리가 정의한 타입이라면
해당 타입의 리졸버를 호출되게 됩니다.
이러한 연쇄적 리졸버 호출은 DFS(Depth First Search)로 구현 되어있을것으로 추측합니다. 이점이 바로 gql이 Graph라는 단어를 쓴 이유가 아닐까 생각합니다.
연쇄 리졸버 호출은 여러모로 장점이 있습니다.
연쇄 리졸버 특성을 잘 활용하면
DBMS의 관계에 대한 쿼리를 매우 쉽고, 효율적으로 처리 할 수 있습니다.
예를들어 gql의 query에서 어떤 타입의 필드 중 하나가 해당 타입과 1:n의 관계를 맺고 있다고 가정해보겠습니다.
리졸버 함수!
인트로스펙션(introspection)
REST의 API 명세서 공유와 같은 문제를 해결하는 것이 gql의 인트로스펙션 기능 입니다.
gql의 인트로스펙션은 서버 자체에서 현재 서버에 정의된 스키마의 실시간 정보를 공유를 할 수 있게 합니다.
이 스키마 정보만 알고 있으면 클라이언트 사이드에서는 따로 연동규격서를 요청 할 필요가 없게 됩니다.
클라이언트 사이드에서는 실시간으로 현재 서버에서 정의하고 있는 스키마를 의심 할 필요 없이 받아들이고, 그에 맞게 쿼리문을 작성하면 됩니다.
이러한 인트로스펙션용 쿼리가 따로 존재합니다.
일반 gql 쿼리문을 작성하듯이 작성하면 됩니다.
다만 실제로는 굳이 스키마 인트로스펙션을 위해 gql 쿼리문을 작성할 필요가 없습니다.
대부분의 서버용 gql 라이브러리에는 쿼리용 IDE를 제공합니다. 다음 화면은 apollo server라는 서버용 gql 라이브러리에 포함되어있는 웹 IDE 화면입니다.
GraphQL을 활용할 수 있게 도와주는 다양한 라이브러리들
gql 자체는 쿼리 언어입니다. 이것 만으로는 할 수 있는 것이 없습니다. gql을 실제 구체적으로 활용 할 수 있도록 도와주는 라이브러리들이 몇가지 존재 합니다.
gql 자체는 개발 언어와 사용 네트워크에 완전히 독립적입니다. 이를 어떻게 활용 할지는 여러분에게 달려 있습니다.
대표적인 gql 라이브러리 셋에 대한 링크는 2개를 소개합니다.
릴레이는 GraphQL의 어머니인 Facebook이 만들었습니다.
하지만 개인적인 의견으로는 현재(2019년 7월)버전의 릴레이는 사용하기 매우 번거롭게 디자인 되어 있다고 생각합니다.
개인적으로는 아폴로가 사용하기 편했습니다.
• 릴레이(Relay)
• 아폴로(Apollo GraphQL)
실제 GraphQL로 비지니스 로직 작성하기
