GraphQL 란??

근래 구직중인데... 우대사항에 GraphQL 이라는 말이 많이 보인다.

그래서 뭔가하고 서칭하면서 정리해보았다!

 

GraphQL(GQL) 이란?

애플리케이션 프로그래밍 인터페이스(API) 를 위한 쿼리 언어, 페이스북에서 만들었다고 한다.

다만 쿼리 언어 중 하나인 SQL 과는 언어 구조 차이가 크므로 활용 측면에서도 차이가 크다고 한다.

• SQL 은 데이터베이스 시스템에서 저장된 데이터를 효율적으로 가져오는 것이 목적 -> 백엔드 시스템에서 사용
• GQL 은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적 -> 클라이언트 시스템에서 사용

 

즉 GQL은 API를 빠르고 유연하게 개발자 친화적으로 만들기 위하여 설계되었다고 하며, GraphiQL 이라는 IDE내에 배포될 수 있다고 함

 

REST를 대체할 수 있는 개념이며 개발자가 단일 API 호출로 다양한 데이터 소스에 데이터를 끌어오는 요청을 구성할 수 있도록 지원한다고 한다.

HTTP API 가 특정 데이터베이스나 플랫폼에 종속적이지 않은 것처럼 GQL 도 특정 데이터베이스나 플랫폼에 종속적이지 않다고 함.

 

장점	단점
GraphQL 호출은 단일 왕복으로 처리되며 클라이언트는 오버페칭 없이 요청한 결과만 얻을 수 있음	데이터 쿼리의 상당 작업을 서버측으로 옮겨 서버 개발자의 작업 복잡성이 커짐
엄격하게 정의된 데이터 유형은 클라이언트와 서버 간 통신의 오류를 줄여줌	고정된 요청과 응답만 필요할 땐 쿼리로 인해 요청의 크기가 REST API보다 커질 수 있음
세부 검사를 수행하여 클라이언트에선 사용 가능한 데이터 유형 목록을 요청을 할 수  있음	캐싱이 복잡
REST API로 사용할 수 없는 기능을 제공이 가능	유지 관리 가능한 스키마를 작성하기 위한 추가 작업이 필요
HTTP 요청 횟수와 응답 사이즈를 줄일 수 있음	파일 업로드 구현 방식이 정해져 있지 않아 직접 구현해야 함

참고 : https://www.redhat.com/ko/topics/api/what-is-graphql

 

 

 

GQL 쿼리의 예시

// GQL 쿼리문
{
	human {
        name
  }
}

// 위의 쿼리문의 응답 데이터
{
	"data" : {
    	"human" : {
        	"name" : "Kim"
        }
    }
}

 

 

REST API와 비교

• REST API는 url과 요청 메서드를 조합하기 때문에 다양한 endpoint 가 존재
• endpoint 마다 데이터베이스sql 쿼리가 달라짐 -> 엔드포인트가 많아질 수록 관리가 힘들고 노출을 막기 위해 추가적 처리가 필요
• 필요한 정보 외에도 다른 정보도 함께 받게 됨

 

• GQL는 불러오는 데이터의 종류를 쿼리 조합으로 결정하기에 하나의 endpoint 가 존재
• gql 스키마 타입마다 데이터베이스 sql 쿼리가 달라짐
• 여러번 네트워크 호출을 할 필요없이 1번의 네트워크 호출로 처리가 가능
• 원하는 데이터만 받을 수 있음

REST API
→ example.com/users
→ example.com/users/{id}
→ example.com/users/{id}/{nickname}

GraphQL
→ example.com/graphql

 

GraphQL 구조

Query / Mutation 를 나누지만 내부적으로 들어가면 별차이가 없음

 

쿼리의 경우 R(Read) 에 사용

Mutation은 데이터의 변조CUD(Create, Upadate, Delete) 에 사용

 

 

오브젝트 타입과 필드

type User {
  name: String!
  imoticon: [Imoticon!]!
}

type 키워드로 오브젝트 타입을 지정해줄 수 있다. 즉 위의 예시는 User 오브젝트 타입이고

필드는 오브젝트 타입 안의 name 과 imoticon 을 의미

! 는 필수 값을 의미하며 [ ]는 배열을 의미함

String 같은 것이 타입을 의미한다.

 

Resolver 리졸버

GQL 은 데이터를 가져오는 구체적인 과정을 직접 구현해줘야하므로

쿼리문 파싱은 대부분의 GQL 라이브러리에서 처리해주지만 데이터를 가져오는 구체적인 과정은 리졸버가 담당하며 이를 직접 구현해줄 필요가 있다고 함

 

Introspection

클라-서버 간 협업에는 API 명세서가 필요하지만 이를 관리하는 것은 제때 업데이트가 되지 않거나 관리가 되지 못하곤 하지만

GQL에서 이러한 API 명세서의 공유 같은 문제를 해결할 수 있는 것이 인트로스펙션 기능이라고 한다.

인트로스펙션은 서버 자체에서 현재 서버에 정의된 스키마의 실시간 정보를 공유할 수 있게 한다.

클라이언트 사이드에서는 따로 연동규격서를 요청할 필요가 없고 실시간으로 서버에서 정의하고 있는 스키마를 받아들이고 쿼리문을 작성해주면 된다.

 

물론 쿼리가 따로 존재하지만 굳이 따로 작성할 필요가 없고 서버용 GQL 라이브러리에 쿼리용 IDE를 제공해준다고 함

 

 

GQL 라이브러리 --

https://relay.dev/

Relay

https://www.apollographql.com/

Apollo GraphQL | Supergraph: unify APIs, microservices, & databases in a composable graph

 

 

간단하게 적어보았는데 솔직히 아직 잘 모르겠다.

REST API를 대체하는 개념은 아니고 프로젝트의 성격을 판단하여 선택하는 개념인 듯 싶다.

그래도 원하는 데이터만 가져올 수 있다는 점은 매력적인 것 같음!