GraphQL

GraphQL 서버는 스키마를 사용하여 사용가능한 데이터의 형태를 설명한다.

이 스키마의 계층 구조 정의 type 과 field 는 백엔드 데이터 저장소로부터 채워진다.

스키마는 또한 클라이언트가 실행할 수 있는 query와 mutation 을 정확히 지정한다.

 

 

 

 

이 포스트는 스키마의 기본 구성 요소와 GraphQL 서버용 구성 요소를 만드는 방법에 대해 설명한다.

 

 

 

 

 

GraphQL 사양은 인간이 읽을 수 있는 스키마 정의 언어인 SDL 을 정의한다.

이는 너가 너의 스키마를 정의하고 그것을 string 으로써 저장하는 것을 의미한다.

 

type Book {
	title: String
    	author: Author
}

type Author {
	name: String
    	books: [Book]
}

 

이런 형식..

 

 

 

 

# This Book type has two fields: title and author

type Book {
	title: String
        author: Author
}

 

각 필드는 지정된 유형의 데이터를 반환하며 필드의 반환 유형은 scalar, object, enum, union, interface 일 수 있다. 

모두 아래에 설명된다.

 

 

 

 

 

 

 

field null 허용 여부

 

type Author {
	name: String!  # Can't return null
    	books: [Book]
}

 

이러한 필드는 null 을 허용하지 않는다.

서버가 nullalbe 이 아닌 필드에 대해 반환을 시도하면 오류가 발생한다.

 

 

 

 

 

 

Null 허용 여부 및 목록

목록 필드를 사용하면 ! 가 두 위치의 조합에 나타날 수 있다.

 

type Author {
	books: [Book!]!  # This list can't be null AND its list *items* can't be null
 }

 

이 대괄호 안에 ! 가 나타나면 반환된 목록에 null 인 항목을 포함할 수 없다.

이 대괄호 외부에 ! 가 나타나면 목록 자체가 null 이 될 수 없다.

어떠한 경우에도, 목록 필드가 빈 목록으로 반환되는 것이 타당하다. (null 은 아님)

 

 

 

 

 

 

GraphQL 스키마의 모든 유형 정의는 다음 범주 중 하나에 속한다.

• Scalar
• Object
• Input
• Enum
• Union
• Interface

 

 

Scalar types

Int

Float

String

Boolean

ID(string 으로 직렬화되는) : 개체를 다시 가져오거나 캐시의 키로 자주 사용되는 고유 식별자이다. 문자열로 직렬화되지만 ID 는 사람이 읽을 수 있도록 고안된 것이 아니다.

 

• Object type

GraphQL 스키마에서 정의하는 대부분의 유형은 객체 유형이다. 개체 유형에는 각각 고유한 유형이 있는 필드 컬렉션이 포함된다.

 

두 객체 유형은 이전의 예제 스키마의 경우와 같이 서로를 필드로 포함할 수 있다.

type Book {
  title: String
  author: Author
}

type Author {
  name: String
  books: [Book]
}

 

 

__typename 필드

스카마의 모든 객체 유형에는 자동으로 이름이 지정된 필드가 있다. __typename(너가 정의할 필요 없음).

__typename 필드는 객체 유형의 이름을 반환한다. string으로써 (예를 들어 Book 또는 Author)

 

 

GraphQL 클라이언트는 다양한 목적으로 한 객체의 __typename 을 사용하는데....

여러유형(예: 공용체= union 또는 인터페이스)을 반환할 수 있는 필드에서 반환된 유형을 결정하는 것과 같은 다양한 목적

Apollo Client 는 __typename 에 의존한다. 결과를 캐싱할 때....

그래서 그것은 자동으로 __typename 을 포함한다. 모든 쿼리의 모든 개체에

 

 

왜냐하면 __typename 은 항상 존재하기때문에 그것은 모든 GraphQL 서버에서도 유효한 쿼리이다.

 

query UniversalQuery {
	__typename
}

 

 

Query 유형

Query유형은 최상위 레벨의 모든 정의하는 특별한 객체 유형 진입 점을 클라이언트가 서버에 대해 실행하는 것이 쿼리.

Query유형 의 각 필드 는 다른 진입점의 이름과 반환 유형을 정의합니다. Query예제 스키마 의 유형은 다음과 유사할 수 있습니다.

 

 

type Query {
  books: [Book]
  authors: [Author]
}

이 Query유형은 books및 2개의 필드를 정의합니다 authors. 각 필드는 해당 유형의 목록을 반환합니다.

REST 기반 API를 사용하면 책과 저자가 다른 끝점(예: /api/books및 /api/authors)에서 반환될 수 있습니다 . GraphQL의 유연성을 통해 클라이언트는 단일 요청으로 두 리소스를 모두 쿼리할 수 있습니다.

 

 

쿼리 구조화

클라이언트가 그래프에 대해 실행할 쿼리를 작성할 때 이러한 쿼리는 스키마에서 정의한 개체 유형의 모양과 일치합니다.

지금까지 우리의 예제 스키마를 기반으로, 클라이언트는 모든 책 제목의 목록을 모두 요청하는 다음 쿼리, 실행할 수 및 모든 저자 이름의 목록을 :

복사

query GetBooksAndAuthors {
  books {
    title
  }

  authors {
    name
  }
}

그러면 서버는 다음과 같이 쿼리 구조와 일치하는 결과로 쿼리에 응답합니다.

복사

{
  "data": {
    "books": [
      {
        "title": "City of Glass"
      },
      ...
    ],
    "authors": [
      {
        "name": "Paul Auster"
      },
      ...
    ]
  }
}

 

 

 

어떤 경우에는 이 두 개의 개별 목록을 가져오는 것이 유용할 수 있지만 클라이언트는 각 책의 저자가 결과에 포함된 단일 책 목록을 가져오는 것을 선호할 것입니다.

스키마의 Book유형에는 유형 author필드 가 있기 때문에 Author클라이언트는 대신 다음과 같이 쿼리를 구성할 수 있습니다.

복사

query GetBooks {
  books {
    title
    author {
      name
    }
  }
}

그리고 다시 한 번, 우리 서버는 쿼리 구조와 일치하는 결과로 응답합니다.

복사

{
  "data": {
    "books": [
      {
        "title": "City of Glass",
        "author": {
          "name": "Paul Auster"
        }
      },
      ...
    ]
  }
}

 

 

 

 

Mutation유형

Mutation유형에 대한 구조 및 목적이 유사 Query유형 . Query유형은 읽기 작업의 진입점을 정의 하는 반면 유형은 쓰기 작업의 Mutation진입점을 정의 합니다.

Mutation유형 의 각 필드 는 다른 진입점의 서명 및 반환 유형을 정의합니다. Mutation예제 스키마 의 유형은 다음과 유사할 수 있습니다.

복사

type Mutation {
  addBook(title: String, author: String): Book
}

이 Mutation유형은 사용 가능한 단일 돌연변이 addBook. 돌연변이는 두 개의 인수( title및 author)를 허용 하고 새로 생성된 Book객체를 반환 합니다. 예상대로 이 Book개체는 스키마에서 정의한 구조를 따릅니다.