GraphQL

1. GraphQL이란?

Graph + Query Language의 줄임말로 오픈 소스로 제공된 쿼리 언어입니다.

API를 위한 쿼리 언어입니다.

 

GraphQL에서 데이터는 그래프 형태로 연결되어 있으며 클라이언트 요청에 따라 유연하게 트리 구조의 JSON 데이터를 응답으로 전송할 수 있습니다.

 

GraphQL의 특징

• GraphQL은 HTTP를 통해 API 서버로 요청을 보내고 응답을 받습니다.
• 응답을 받을 시, 데이터 결과를 JSON 형식으로 받습니다.
• GraphQL은 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있습니다.
• GraphQL은 GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사합니다.

 

2. GraphQL 구조

• Query: 저장된 데이터 가져오기 (REST의 GET과 비슷)
• Mutation: 저장된 데이터 수정하기
  • Create: 새로운 데이터 생성
  • Update: 기존의 데이터 수정
  • Delete: 기존의 데이터 삭제
• Subscription: 특정 이벤트가 발생 시 서버가 대응하는 데이터를 실시간으로 클라이언트에게 전송

 

2-1. 쿼리(query, 데이터 조회)

hero 필드의 name  쿼리

{
  hero {
    name
  }
}

쿼시 실행 결과 

{
  "data": {
    "hero": {
      "name": "R2-D2"
    }
  }
}

전달인자(Arguments)

필드에 전달인자를 추가하게 되면 전달인자로 제한된 원하는 데이터만 받을 수 있습니다.

 // id가 1000인 human의 name과 height를 쿼리

 {
  human(id: "1000") {
    name
    height
  }
}

별명(Aliases)

필드 이름을 중복해서 사용할 수 없으므로, 필드 이름을 중복으로 사용해서 쿼리를 해야 할 때는 별명을 붙여서 쿼리를 합니다.

// hero 필드 이름이 겹치므로 별명을 붙여준다
{
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}

오퍼레이션 네임(Operation name)

오퍼레이션 타입에는 query, mutation, subscription, describes 등이 있습니다. 쿼리를 약식으로 작성하지 않는 한 이런 오퍼레이션 타입은 반드시 필요합니다. 오퍼레이션 네임을 작성할 때는 오퍼레이션 타입에 맞는 이름으로 작성하는 것이 가독성이 좋습니다.

// query keyword와 query name을 작성
query HeroNameAndFriends {
  hero {
    name
    friends {
      name
    }
  }
}

변수(Variables)

동적으로 인수를 받고 싶을 때 변수를 사용합니다.

query HeroNameAndFriends($episode: Episode) {
  hero(episode: $episode) {
    name
    friends {
      name
    }
  }
}

$episode: Episode 일 때, 뒤에 !가 붙는다면 episode는 반드시 Episode여야 한다는 뜻입니다. !는 옵셔널한 사항입니다.

 

2-2. 뮤테이션(mutation, 데이터 수정)

GraphQL은 mutation이라는 키워드를 사용하여 서버 측 데이터를 수정합니다.

 

2-3. 스키마/타입(Schema/Type)

Schema는 데이터베이스에서 데이터의 구조, 제약 조건, 관계 등을 정의하는 것을 말합니다.

 

2-4. 리졸버(Resolver)

스키마를 정의하면 그 스키마 필드에 사용되는 함수의 실제 행동을 Resolver에서 정의합니다. Query나 Mutation과 같은 요청을 받았을 때, 해당 요청을 처리하고 결과 값을 반환하는 함수입니다.

또한 이러한 함수들이 모여 있기 때문에 보통 Resolvers라 부릅니다.

 

3. GraphQL vs REST API

클라이언트가 서버에서 데이터를 요청하면 서버는 Date Base에 접근해 데이터를 찾습니다. 이때 데이터를 찾는 행위를 데이터(DB)를 조작한다라고 합니다.

 

DB를 조작할 때 사용하는 언어를 Quer Language라고 합니다.  그렇다면 "쿼리를 날리다"는 말은 어떤 말일까요?

여기서 뭐리는 query srting과 path variable를 의미합니다.

예를들어 http://www.example.com/user/123/job="progarmmer" & age=16에서 123이 path variable,ob="progarmmer" & age=16이query srting입니다. 

즉, 쿼리를 날린다는 것은  query srting과 path variable를 사용해 데이터를 요청하는 것입니다. 하지만 이런  REST API에는 한계가 있습니다. 이 한계를 극복하기 위해 GraphQL가 등장하게 되었습니다.

 

REST API의 한계

• Overfetch: 필요 없는 데이터까지 제공함
• Underfetch: endpoint 가 필요한 정보를 충분히 제공하지 못함
• 클라이언트 구조 변경 시 엔드포인트 변경 또는 데이터 수정이 필요함

 

GraphQL의 장단점

• 하나의 endpoint 요청
  • /graphql이라는 하나의 endpoint 로 요청을 받고 그 요청에 따라 query , mutation을 resolver 함수로 전달해서 요청에 응답합니다. 모든 클라이언트 요청은 POST 메소드를 사용합니다.
• No! under & overfetching
  • 여러 개의 endpoint 요청을 할 필요없이 하나의 endpoint에서 쿼리를 이용해 원하는 데이터를 정확하게 API에 요청하고 응답으로 받을 수 있습니다.
• 강력한 playground
  • graphql 서버를 실행하면 playground라는 GUI를 이용해 resolver 와 schema 를 한 눈에 보고 테스트 해 볼 수 있습니다. (POSTMAN 과 비슷합니다.)
• 클라이언트 구조 변경에도 지장이 없음
  • 클라이언트 구조가 바뀌어도 필요한 데이터를 결정하고 받는 주체가 클라이언트이기 때문에 서버에 지장이 없습니다. 클라이언트에서는 무슨 데이터가 필요한 지에 대해서만 요구사항을 쿼리로 작성하면 됩니다.

 

GraphQL의 단점

• REST API에 친숙한 개발자의 경우 GraphQL를 학습하는 데 시간이 필요합니다.
• 캐싱이 REST보다 훨씬 복잡합니다.
  • HTTP에선 각 메소드에 따라 캐싱이 구현되어 있습니다. 하지만 GraphQL에선 POST 메소드만을 이용해 요청을 보내기 때문에 각 메소드에 따른 캐싱을 지원받을 수 없습니다. 그래서 이를 보완하기 위해 Apollo 엔진의 캐싱과 영속 쿼리 등이 등장하게 되었습니다.
• 고정된 요청과 응답만 필요할 경우에는 Query 로 인해 요청의 크기가 RESTful API 의 경우보다 더 커집니다.

 

참고) 코드스트테이츠 유어클래스