Graphql

현재 회사에서 rest api대신 Graphql을 채택해서 사용하고있다.
써본적 없는 기술이었지만, 빠른 적응을 위해 뚝딱뚝딱했다
6개월정도 써보고 있는데, rest를 마이크로 서비스 환경에서 써본적은 없지만... 클라와 서버와의 커뮤니케이션에서 편하다(?) 라는 느낀점이 있다.
마이크로 서비스니까 서버쪽이어도 다른 서비스에 요청을 해야하니..
그리고 무지성으로 쓰느라 내부에서 어떻게 동작하는지 모르니 공부해보도록 한다

쿼리 뮤테이션 사용법은 다른 분들이 훨씬 잘 정리해주셨을거라 생각해서 스킵한다.

 

Graphql

• GraphQL은 API를 위한 쿼리 언어이며 타입 시스템을 사용하여 쿼리를 실행하는 서버사이드 런타임이다.
• 일반적인 REST API는 여러 URL에서 데이터를 받아와야 하지만 GraphQL API는 한번의 요청으로 앱에 필요한 모든 데이터를 가져온다. => 엔드포인트가 하나다, 오버 언더페칭 될 일이 없다

  

 

Graphql 내부 동작과정

1. 쿼리 요청 때림
2. GraphQL 쿼리 구문 분석
   - 추상 구문 트리로 변환된다(AST)
3. 쿼리 및 스키마 유효성 검사
   유효성 검사 프로세스는 중복 필드 이름, 모호한 필드 및 기타 불일치에 대한 스키마와 쿼리의 유효성을 검사한다.
   유효성 검사기는 쿼리 구문 분석 결과(queryAST) 및 스키마를 통해 실행 되고 Document, Operations, Fields, Arguments, Variables, Fragments, Directives, Values의 유효성 을 확인한다.
4. 쿼리 실행

쿼리 구문 분석 결과

 

여담으로 마이크로 서비스 환경에서 다른 서비스의 api를 이용할때 그 api generate해서 사용하는 경우가 있는데 
이 경우에 해당 타입대로 모든 필드를 generating 해야 타입의 모든 필드를 사용할 수 있게 되는데,
이럴 경우, 사용 하는 필드만 다른 api 에서 요청하는게 아니라 모든 필드를 요청하기 때문에 graphql의 장점을(오버페칭 X) 살리지 못하기 때문에 비효율적이어서 delegateToSchema로 리팩토링을 한 적이 있는데, 이렇게 하게 되면 요청하는 필드만 selectionSet으로 넘어가서 요청할 수 있게 된다.
그때 info에 담긴 queryAST를 다루면서 이게 뭐지..? 싶었는데 
저 정보의 정체를 이제야 알았다 하하
찾아보니, 스키마도 AST로 변환되고 리졸버의 info 인자 내에서 사용할 수 있다고 한다.