본문 바로가기
공부/etc

GraphQL 공부 - 2

by Piva 2021. 8. 23.

https://www.howtographql.com/basics/0-introduction/

 

Learn GraphQL Fundamentals with Fullstack Tutorial

Learn all about GraphQL and why it is an API technology that's superior to REST. It is not only for React & Javascript developers but can be used for any API.

www.howtographql.com

  위 튜토리얼 사이트의 내용을 조금 번역&정리한 걸 업로드.

 


Defining a Schema

: 스키마는 GraphQL API를 작업하는 데 있어서 가장 중요한 개념 중 하나.

→ API의 능력을 특정하고 클라이언트에서 어떻게 데이터를 요청할 수 있는지를 정의하기 때문.

→ 일반적으로 스키마는 간단히 'GraphQL Type들의 모음'이라고 볼 수 있지만, 스키마를 작성하는 데에 있어 몇 가지 특별한 root type들이 존재함.

 

type Query { ... }
type Mutation { ... }
type Subscription { ... }

Query, Mutation, Subscription 타입은 클라이언트가 보낸 요청들의 엔트리 포인트가 됨.

 

 

- Query 타입은 다음과 같이 작성됨.

type Query {
  allPersons: [Person!]!
}

→ 저번 예시로 나온 allPersons 쿼리를 날릴 수 있게 해주는 Query 타입.

→ allPersons는 API의 root 필드

 

 

- 매개변수가 포함된 Query는 다음과 같이 작성.

type Query {
  allPersons(last: Int): [Person!]!
}

 

 

- Mutation 타입 또한, root type으로 Mutation을 사용하여 작성.

type Mutation {
  createPerson(name: String!, age: Int!): Person!
}

 

 

- Subscription 타입은 다음과 같이 작성.

type Subscription {
  newPerson: Person!
}

 

 

- 여태까지 나온 Person 타입에 대한 모든 쿼리와 Mutation들을 합치면 다음과 같은 스키마를 작성할 수 있음.

type Query {
  allPersons(last: Int): [Person!]!
  allPosts(last: Int): [Post!]!
}

type Mutation {
  createPerson(name: String!, age: Int!): Person!
  updatePerson(id: ID!, name: String!, age: String!): Person!
  deletePerson(id: ID!): Person!
}

type Subscription {
  newPerson: Person!
}

type Person {
  id: ID!
  name: String!
  age: Int!
  posts: [Post!]!
}

type Post {
  title: String!
  author: Person!
}

Big Picture(Architecture)

Use Cases

: 해당 튜토리얼에서 구축할 아키텍처는 3종류.

  1. DB와 연결된 GraphQL 서버
  2. 하나의 GraphQL API로 다수의 서드 파티 or 레거시 시스템을 통합시키는 GraphQL 서버(GraphQL layer that integrates existing systems)
  3. A hybrid approach of a connected database and third party or legacy systems that can all be accessed through the same GraphQL API

 

1. DB와 연결된 GraphQL 서버

: Greenfield 프로젝트에서 가장 흔한 아키텍처 (Greenfield 프로젝트 : 없는 상태에서 새롭게 인프라 자산(asset)을 건설하는 프로젝트)

→ 쿼리가 GraphQL 서버에 도착하면, 서버는 쿼리의 payload를 읽고 요구되는 데이터를 DB에서 가져옴.

⇒ 이를 (쿼리를) resolving 이라고 함.

→ GraphQL은 DB의 종류나 네트워크 프로토콜을 가리지 않음.

 

 

2. GraphQL layer that integrates existing systems

: 하나의 GraphQL API로 다양한 시스템을 통합하는 것.

 

 

3. Hybrid approach with connected database and integration of existing system

: 위의 두 가지 접근법을 융합한 것

→ DB와 연결되어 있으면서 타 서드 파티 or 레거시 시스템과도 통신하는 GraphQL 서버.

⇒ 서버에서 쿼리를 받으면, 이를 resolve하고 DB나 API들에서 요구되는 데이터를 가져옴.

 

 

 

Resolver Functions

- resolver

: GraphQL 쿼리(혹은 Mutation)의 payload는 field들로 구성되어 있음.

→ GraphQL 서버에서는 각 필드가 단 하나의 함수에 응답함.

⇒ 이 함수를 resolver라고 함.

⇒ resolver 함수의 목적은 '해당 필드의 데이터를 가져오는 것'

→ 서버가 쿼리를 받으면 그 쿼리의 payload에 명시된 field들의 함수들을 호출함.

→ 이를 통해 쿼리를 'resolve(해결)'하고, 각 field에 맞는 데이터를 가져옴.

→ 모든 resolver들이 반환되면, 서버가 쿼리에 명시된 형식으로 데이터를 package화 하여 클라이언트에게 보냄.

 

 

GraphQL Client Libraries

  • REST API를 사용할 때는 대부분의 어플리케이션이 다음 과정을 거침.
  1. HTTP 요청을 보냄.
  2. 서버 응답을 받고 파싱함.
  3. 데이터를 로컬에 저장(메모리 등으로).
  4. 데이터를 UI에 보임.

→ '서술적인(declarative)' 데이터 접근 방식을 사용하면, 클라이언트에서 다음의 과정을 거치지 않아도 됨.

  1. 데이터 요구사항을 묘사.
  2. 데이터를 UI에 보임.