GraphQL 1장 - 개념학습

Interview

GraphQL

• 페이스북에서 만든 쿼리 언어이다.
• 서버에서 데이터를 받아오는 쿼리 언어인데, 데이터 베이스에서 클라이언트가 필요한 데이터를 명시적으로 요청할 수 있어 필요하지 않은 데이터는 가져오지 않아도 되는 장점이 있다.
• 데이터를 다루고 처리하는 비율은 계속해서 변동하지만, 계속해서 상위권을 차지하고 있다.

Graph 사용 이유

• Graph 에서는 모든 데이터가 그래프 형태로 연결되어 있다고 전제한다.
• GraphQL은 클라이언트 요청에 따라 유연하게 트리 구조의 JSON응답으로 전송할 수 있다.
• REST API 방식의 고정된 자원이 아닌 클라이언트 요청에 따라 유연하게 자원을 가져올 수 있다는 점에서 이점을 갖는다.

GraphQL 그래프 순회

• 그래프를 순회하기 위해 도서관의 도서 목록 시스템을 구축한다고 가정했을 때, 하나의 도서 목록에는 많은 책과 저자가 있을 것이며, 각 책에는 최소한 한 명의 저자가 있다.

• 그래프 예시는 설명한 관계를 그래프 형태로 시각화한 것이며, 이런 식으로 그래프로 표현하게 되면 우리가 가지고 있는 데이터의 조각들이나 나타내고자 하는 엔티티(책 혹은 저자) 간의 관계를 나타낼 수 있다.

• 엔티티는 사물의 구조나 상태, 동작 등을 모델로 표현하는 경우 그 모델의 구성요소를 말한다.
  • 책이라는 객체가 존재한다면 “책이름”이 1개의 속성으로 구성되어 있는 것이다.
  • 정보의 측면에서 볼 때 이 속성은 그 자체만으로는 중요한 의미를 표현하지 못하기 때문에 단독으로 존재하지는 못한다.
  • 앞의 예에서 각 속성들 “학번”, “이름”, “학과”는 개별적으로는 우리에게 어떤 정보를 제공해 주지 못하지만 이것들이 모여 “학생”이라는 객체를 구성해서 표현할 때는 큰 의미를 제공할 수 있게 된다.

그래프에서 트리 추출하는 방법

{
	책 : {
		책이름 : "GraphQL은 어렵지 않다",
		저자 : [
			{ 이름 : "김코딩"},
			{ 이름 : "박해커"},
		]
	}
}

GraphQL의 특징

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

GraphQL vs REST API

REST API의 한계

• 가상의 블로그 앱을 구현한다고 가정했을 때, 사용자의 이름, 포스팅 목록, 팔로워 목록의 데이터를 가져오고 싶다.
• Overfetch : 필요 없는 데이터까지 제공하여 응답 데이터가 유저의 주소, 생일 등과 같이 클라이언트에게 필요없는 정보를 포함하고 있을 수 있다.
• Underfetch : endpoint가 필요한 정보를 충분히 제공하며 못하며 필요한 정보를 모두 확보하기 위해 추가적인 요청을 보내야만 한다.
  • 필요한 정보를 모두 가져오려면 REST API에서는 각각의 자원에 따라 엔드포인트를 구분하기 때문에 3가지 엔드포인트에 요청을 보내야한다.
• 클라이언트 구조 변경 시 엔드포인트 변경 또는 데이터 수정이 필요하다.
  • 클라이언트가 직접 데이터의 형태를 결정할 수 없고 만약 필요한 데이터의 내용이 변할 경우 다른 endpoint를 통해 변경된 데이터를 가져오거나 수정해야 한다.

GraphQL

• REST API는 Resource에 대한 형태 정의와 데이터 요청 방법이 연결되어 있지만, GraphQL에서는 Resource에 대한 형태 정의와 데이터 요청이 완전히 분리되어 있다.
• REST API는 Resource의 크기와 형태를 서버에서 결정하지만, GraphQL에서는 Resource에 대한 정보만 정의하고, 필요한 크기와 형태는 클라이언트 단에서 요청 시 결정한다.
• REST API는 URI가 Resource를 나타내고 Method가 작업의 유형을 나타내지만, GraphQL에서는 GraphQL Schema가 Resource를 나타내고 Query, Mutation 타입이 작업의 유형을 나타낸다.
• REST API는 여러 Resource에 접근하고자 할 때 여러 번의 요청이 필요하지만, GraphQL에서는 한번의 요청에서 여러 Resource에 접근할 수 있습니다.
• REST API에서 각 요청은 해당 엔드포인트에 정의된 핸들링 함수를 호출하여 작업을 처리하지만, GraphQL에서는 요청 받은 각 필드에 대한 resolver를 호출하여 작업을 처리합니다.

GraphQL의 장점

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

GraphQL의 장점

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

GraphQL의 단점

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

GraphQL 구조

GraphQL Keywords

• 서버로부터 데이터를 조회(Read)하는 경우, REST API에선 GET 요청이 있었다면 GraphQL에서는 Query를 이용해 원하는 데이터를 요청할 수 있다.
• Create, Delete와 같이 저장된 데이터를 수정하는 경우에는 Mutation을 이용해 이를 수행할 수 있다.
• GraphQL에서는 구독(Subscription)이라는 개념을 제공하며 이를 이용해 실시간 업데이트를 구현할 수 있다.
• Subscription는 전통적인 Client(요청)-Server(응답) 모델을 따르는 Query 또는 Mutation과 달리, 발행/구독(pub/sub) 모델을 따른다.
• 클라이언트가 어떤 이벤트를 구독하면, 클라이언트는 서버와 WebSocket을 기반으로 지속적인 연결을 형성하고 유지하게 된다.
• 그 후 특정 이벤트가 발생하면, 서버는 대응하는 데이터를 클라이언트에 푸시해준다.
  • Query: 저장된 데이터 가져오기 (REST의 GET과 비슷합니다.)
  • Mutation: 저장된 데이터 수정하기
  • Create: 새로운 데이터 생성
  • Update: 기존의 데이터 수정
  • Delete: 기존의 데이터 삭제
  • Subscription: 특정 이벤트가 발생 시 서버가 대응하는 데이터를 실시간으로 클라이언트에게 전송

쿼리

필드

{
  hero {
    name
  }
}

• 결과

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

• 필드의 name은 String 타입을 반환한다.
• 위의 경우 hero의 name이 “R2-D2”임을 알 수 있다.
• 보이는 것처럼 쿼리와 결과가 정확하게 같은 모양을 하고 있음을 확인할 수 있는데, 이 부분은 GraphQL에 있어서 필수적이라고 볼 수 있다.
• GraphQL은 서버에 요청했을 때 예상했던 대로 돌려받고, 서버는 GraphQL을 통해 클라이언트가 요구하는 필드를 정확히 알기 때문이다.

전달인자

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

• 결과

  {
    "data": {
        "human": {
            "name": "Luke Skywalker",
            "height": 1.72
        }
    }
  }
  

• 이런 식으로 id가 1000인 human의 이름과 키를 쿼리해 올 수 있다.
• REST와 같은 시스템에서는 단일 인수 집합(요청의 쿼리 매개변수 및 URL 세그먼트)만 전달할 수 있다.
• 예를 들어 REST API를 이용한다면 ?id=1000 이거나 /1000(/:id)일 때와 같은 목적으로 쿼리할 수 있다.

별명

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

{
  hero(episode: EMPIRE) {
    name
  }
  hero(episode: JEDI) {
    name
  }
}

{
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}

• 결과

  {
    "data": {
        "empireHero": {
            "name": "Luke Skywalker"
            },
            "jediHero": {
                "name": "R2-D2"
            }
        }
  }
  

오퍼레이션 네임

• 여태껏 쿼리와 쿼리 네임을 모두 생략하는 축약형 구문을 사용했지만, 실제 앱에서는 코드를 모호하지 않게 작성하는 것이 중요하다.

query HeroNameAndFriends {
  hero {
    name
    friends {
      name
    }
  }
}

• 결과

  {
    "data": {
        "hero": {
            "name": "R2-D2",
            "friends": [
                {
                    "name": "Luke Skywalker"
                },
                {
                    "name": "Han Solo"
                },
                {
                    "name": "Leia Organa"
                }
            ]
        }
    }
  }
  

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

변수

• 여태껏 고정된 인수를 받아 쿼리했지만, 실제 앱을 사용할 때는 고정된 인수를 받는 것보다는 동적으로 인수를 받아 쿼리하는 경우가 대다수이다.
• 변수는 그런 인수들을 동적으로 받고 싶을 때 사용한다.
• 오퍼레이션 네임 옆에 변수를 $변수 이름: 타입 형태 로 정의한다.
• 예시처럼 $episode: Episode 일 때, 뒤에 !가 붙는다면 episode는 반드시 Episode여야 한다는 뜻이다.

• !는 옵셔널한 사항이다.

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

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

• GraphQL은 대개 데이터를 가져오는 데에 중점을 두고 있지만 서버측 데이터를 수정하기도 한다.
• REST API에서 GET 요청을 사용하여 데이터를 수정하지 않고, POST 혹은 PUT 요청을 사용하는 것처럼 GraphQL도 유사하다.

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

  mutation CreateReviewForEpisode($ep: Episode!, $review: ReviewInput!) {
  createReview(episode: $ep, review: $review) {
      stars
      commentary
  }
  }
  

스키마/타입(Schema/Type)

• GraphQL 스키마의 가장 기본적인 구성 요소는 서비스에서 가져올 수 있는 객체의 종류, 그리고 포함하는 필드를 나타내는 객체 유형이다.
• Character는 GraphQL 객체 타입이며, 즉 필드가 있는 타입임을 의미한다.
• 스키마에 있는 대부분의 타입은 객체 타입이다.
• name 과 appearIn 은 Character 타입의 필드다.
• name 과 appearIn 은 GraphQL 쿼리의 Character 타입 어디서든 사용할 수 있는 필드다.
• String은 내장된 스칼라 타입 중 하나다.
• 이는 단일 스칼라 객체로 확인되는 유형이며 쿼리에서 하위 선택을 가질 수 없다.
• 스칼라 타입에는 ID, Int도 있다.
• !가 붙는다면 이 필드는 nullable하지 않고 반드시 값이 들어온다는 의미이다.
• 이것을 붙여 쿼리한다면 반드시 값을 받을 수 있을 것이란 예상을 할 수 있다.
• [ ]는 배열을 의미한다.
• 배열에도 !가 붙을 수 있다.
• 여기서는 ! 이 뒤에 붙어 있어 null 값을 허용하지 않으므로 항상 0개 이상의 요소를 포함한 배열을 기대할 수 있게 된다.

type Character {
  name: String!
  appearsIn: [Episode!]!
}

리졸버(Resolver)

• 요청에 대한 응답을 결정해주는 함수로써 GraphQL의 여러 가지 타입 중 Query, Mutation, Subscription과 같은 타입의 실제 일하는 방식 즉 로직을 작성한다.
• 다시 말해 위와 같이 스키마를 정의하면 그 스키마 필드에 사용되는 함수의 실제 행동을 Resolver에서 정의한다.
• 이러한 함수들이 모여 있기 때문에 보통 Resolvers라 부른다.

const db = require("./../db")
const resolvers = {
  Query: { // **Query :** 저장된 데이터 가져오기 (REST 에 GET 과 비슷합니다.)
		getUser: async (_, { email, pw }) => {
			db.findOne({
				where: { email, pw }
			}) ... // 실제 디비에서 데이터를 가져오는 로직을 작성합니다.
			...
		}
  },
  Mutation: { // **Mutation :** 저장된 데이터 수정하기 ( Create , Update , Delete )
		createUser: async (_, { email, pw, name }) => {
			...
		}
  }
  Subscription: { // **Subscription :** 실시간 업데이트
    newUser: async () => {
      ...
		}
  }
};

실습해보기

GraphQLAPI{target=”_blank”}