GraphQL을 알아보자

룸잉·2024년 4월 24일

📌 GraphQL

REST API
- 일부 속성만 필요한 경우에도 전체 데이터를 불러온다.
- 서비스 크기가 커질수록 다루는 양의 크기가 커질 경우 서버 부하, 데이터 전송 속도 및 크기 등 Overfetching으로 인한 이슈가 발생할 수 있다. ~~(클라이언트 입장에서는 필요한 데이터만 골라서 사용하면 되긴 하지만)~~
Graph QL
- 필요한 필드만을 명시적으로 요청하여 필요한 정보들만 선택하여 받아올 수 있다.
```
query {
    teams {
        id
        manager
        mascot
    }
}
```
- 전체 데이터를 받아오지 않고 필요에 따라 원하는 데이터만 받아오기 때문에, 데이터 전송량이 감소한다. 이로써 REST API에서 언급했던 Overfetching 이슈를 해결할 수 있다.

REST API
- 특정 데이터를 받아오기 위해 여러 개의 endpoint를 사용해야 한다. 하나의 데이터를 가져오기 위해 n개의 endpoint를 거치기도 한다. 이는 서버 부하, 네트워크 오버헤드 등을 유발할 수 있다.
Graph QL
- 중첩된 필드를통해 여러 객체와 관련된 데이터를 한 번에 요청할 수 있다. 이를 통해 하나의 endpoint에서 여러 계층의 정보들을 한 번에 받아올 수 있다.
```
query {
    team(id: 2) {
        id
        manager
        mascot
        members {
            first_name
            last_name
        }
    }
    
    rolse {
        id
        requirement
    }
}
```
- 하나의 endpoint에서 모든 요청을 해결할 수 있기 때문에, 요청 횟수가 감소한다. 즉, 여러 번 네트워크를 호출할 필요가 없기 때문에 REST API의 Underfetching 이슈를 해결할 수 있다.

: 정보를 읽어오기 위해 사용하는 메소드 - CRUD의 R

응답: 쿼리문에 대한 응답이 데이터로 반환

{
	"data" : {
		"user" : {
			"name" : "abcde"
		}
	}
}

: 받아온 정보를 변형하기 위해 사용하는 메서드 - CRUD의 CUD

: 실시간으로 변경된 데이터를 가져오기 위한 요청 방식

웹 소켓을 통해 소켓 통신을 열어두고, 데이터 업데이트 시 알리는 방식으로 이뤄진다.

: GraphQL 타입 시스템과 데이터를 표현하는 방법

반복되는 필드의 집합을 하나의 요소로 정의하여 이를 재사용할 수 있다.
같은 필드를 순서대로 요청한다고 가정해보자. 필드를 최소 2번은 반복해야 하기 때문에, 중복되는 코드의 양이 늘어나고 쿼리가 복잡해진다. 이러한 경우 fragment를 사용하면 필드셋을 구성한 다음 필요한 쿼리에 포함시킬 수 있다.

Operation type: Query(읽기), Mutation(데이터를 변경하고 가져옴), Subscription(실시간으로 변경된 데이터를 가져옴)

Operation name: 의미있고 명시적인 이름으로 하는 것이, 디버깅이나 서버측에서 로깅하는데 유용하다.

# Operation type: query
# Opertation name: HeroNameAndFriends
query HeroNameAndFriends {
  hero {
    name
    friends {
      name
    }
  }
}

API 명세서 대신 사용할 수 있는 GraphQL 기능
서버 자체에서 현재 서버에 정의된 스키마의 실시간 정보를 공유할 수 있다.
인트로스펙션용 쿼리가 따로 존재하며, 일반 gql문을 작성하듯이 작성하면 된다. 다만, 대부분 서버용 gql 라이브러리에는 쿼리용 IDE를 제공하기 때문에, 실제로는 스키마 인트로스펙션을 위해 ql 쿼리 문을 작성할 필요는 없다.