Deview로 알아보는 GraphQL

💡GraphQL 개요

1. GraphQL이란 무엇인가요?

GraphQL은 페이스북에서 만든 쿼리 언어입니다.
QL이 들어가서 뭔가 SQL(Structured Query Language)와 동일할 것 같지만, GraphQL은 웹 클라이언트와 서버 사이에 사용되는 Query Language입니다.

SQL은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가지고 오는 것이 목적인 반면, GQL은 웹 클라이언트가 서버로부터 데이터를 효율적으로 가져오는 것이 목적입니다. 코드 상으로 보면 다음과 같이 확연하게 두 언어의 차이를 확인할 수 있습니다.

SELECT plot_id, species_id, sex, weight, ROUND(weight / 1000.0, 2) FROM surveys;

/SQL 쿼리 예시

 

{
  hero {
    name
    friends {
      name
    }
  }
}

/GQL 쿼리 예시

쿼리로만 봤을 때 뭔가..객체 지향이 떠오르죠? 실제로 어느정도 객체지향 패러다임을 가지고 있답니다!

 

2. 그래서 GraphQL은 어떻게 작동하나요? REST API와의 차이점은요?

GraphQL은 API Layer에서 작동하는 쿼리언어라고 했었죠.

정의만 봤을 때는 REST API와 별다른 차이점이 없어 보이는데요, 실제 데이터 조회 방식을 통해 REST API와 GraphQL간의 차이점을 알아보겠습니다.

REST 방식에서는 아래와 같이 특정 URL로 요청을 보내고, 그 요청에 해당하는 데이터를 다시 클라이언트에게 전달합니다. 하지만 사용자가 원하는 데이터를 조회하려면 서버 측에서 요구하는 데이터를 제공해줘야 합니다.

그러나 GraphQL은 요청 사항에 받고 싶은 데이터만을 명시하여, 하나의 URL로 통일되어 서버에 요청이 가능합니다.

 

GraphQL 데이터 조회 방식 예시

REST API는 URL, METHOD(get,post…)등을 조합하기 때문에 다양한 Endpoint가 존재 합니다. 반면, gql은 단 하나의 Endpoint(POST)가 존재 합니다. 또한, gql API에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정 합니다.

REST API와 GQL의 차이점을 간단하게 도식화한다면 아래와 같은 그림으로 나타낼 수 있습니다.

REST API vs GraphQL API

 

GraphQL의 특징을 정리하면 다음과 같이 세 가지로 요약할 수 있습니다.

1. 단일 요청으로 많은 데이터를 가져올 수 있다.
2. 가능한 케이스를 타입 시스템으로 표현할 수 있다.
3. 필요한 것만을 요청하고 받아올 수 있다.

아래 네이버에서 실제로 사용하고 있는 케이스와 함께 GraphQL 구조를 이해해봅시다.

 

💡GraphQL 사용 사례 - ‘하나의 네트워크 호출’

네이버 My플레이스 기능은 다양한 데이터 소스를 요구하는 호출이 빈번합니다.

예시로 메인 페이지를 살펴보면, 유저 데이터의 경우 내부 자체 데이터베이스, 기타 데이터의 경우 외부 API를 사용하고 미션 달성 시 N pays로 연결되는 등 여러 데이터 소스를 사용하고 있는데요.
GraphQL을 사용할 경우 하나의 네트워크 호출로 효율적으로 처리가 가능합니다.

하나의 네트워크 호출로 처리된다는 개념이 직관적으로 와 닿지 않을 수 있는데요,
GraphQL의 개념을 살펴보면서 케이스를 살펴보겠습니다.

 

💡GraphQL 사용 사례 - ‘Schema’

GraphQL에는 Schema라고하는 개념이 있습니다. 그러나 데이터베이스 상에서 일반적으로 통용되는 Schema와는 조금 다른데요.

Database 상에서 사용되는 Schema는 데이터를 R/W하기 위한 최적화 방식을 관계와 참조(정규화)로 해소하는 반면, GraphQL 상에서의 Schema는 ‘데이터 타입의 집합’을 의미합니다. view에서 사용되는 데이터 구조를 기반으로 스키마를 작성하게 됩니다.

GraphQL Schema는 type이라는 단위로 이루어져 있어서, 클라이언트 중심으로 Type을 설정하게 됩니다.

GraphQL Shema Type 예시

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

 

따라서 클라이언트는 데이터 소스를 알 필요 없이, GraphQL의 Schema만을 바라보게 되며, View에서 요청하는 데이터만을 호출할 수 있습니다.

 

💡 GraphQL 사용 사례 - ‘Field Argument’

네이버 Myplace 내 마이 페이지에는 다양한 크기의 썸네일들이 있습니다. 일반적으로는 썸네일에 대해서 클라이언트가 리사이징된 이미지를 받아서 사용을 하는데요.

GraphQL에서는 다음과 같이 썸네일이 필요하다고 했을 때, 다음과 같이 설계할 수 있습니다.

type Profile {
 name: String
 thumbnailUrl: String
 }

그런데 만약 프로필 타입이 다른 지면에 노출이 되면서, 요구되는 썸네일의 크기가 달라진다면 어떻게 구현할 수 있을까요?

type Profile {
 name: String
 thumbnailUrl: String
 bigThumbnailUrl: String
 bigThumbnailUrl_100px: String
 reviewThumbnailUrl: String
 bigReviewThumbnailUrl: String
 bigReviewThumbnailUrl_200px: String
 }

조금 비효율적이고, 직관적이지 않다는 생각이 듭니다.
이러한 문제를 해결하기 위해, GraphQL에서는 Field Argument라고 하는 기능을 제공합니다.

클라이언트에서 원하는 인자값만을 받을 수 있도록, Field에 원하는 값을 인자로 받도록 설정할 수 있습니다.

 

User라고하는 Schema의 type에 이미지를 인자값을 받도록 설정하고, 실제로 해당 유저에 대해 Client에서 사이즈를 요청할 때 하기와 같이 쿼리를 작성하여 Filed를 추가로 작성할 필요 없이 호출이 가능합니다.

또한, 지원하는 이미지 사이즈를 모른다고 하더라도 px에 대한 데이터 규격을 제한할 수 있습니다.
이러한 데이터 규격의 제한을 enum이라고 하는 타입을 통해 할 수 있습니다.

이미지의 크기를 enum 타입을 통해 정의하고, User타입에서 Image에 대한 인자값이 없을 경우를 대비하여 기본 인자값을 설정할 수 있도록 할 수 있습니다.
Field Argument와 enum 타입을 사용하면, 다음과 같이 스키마를 간단하게 정의할 수 있습니다.

 

 

💡GraphQL 사용 사례 - ‘Error Handling’

서비스 내에서 닉네임을 생성한다고 했을 때, 설정에 대해 여러가지 규칙들이 존재합니다.
닉네임이 실제로 사용 가능할 수도 있고, 중복되어서는 안될 수도 있고, 금칙어 사용으로 인해 생성이 불가능할 수도 있죠.

GraphQL로 닉네임 설정에 대해 스키마를 설계한다고 했을 때, 오류 코드를 어떻게 관리할 수 있을까요?

아래와 같이 스키마를 설계할 수 있을 것 같은데요.

type ValidateNicknameResult {
 success: Boolean!
 isDuplicate: Boolean!
 words: [String!]!
} 

그런데 만약 해당 스키마에 1일 5회 제한이라는 정책을 추가하게 된다면 타입을 어떻게 변환해야 할까요?

type ValidateNicknameResult {
 success: Boolean!
 isDuplicate: Boolean!
 words: [String!]!
} isCountOver: Boolean!
 todayCount: Int!
}

success 필드가 true일 때 isCountOver 필드도 True라면, 클라이언트가 어떻게 분기를 해야 할지 모호해질 수 있습니다.

이러한 모호성을 줄이고, 여러 개의 타입들을 간결하게 구현하기 위해 GraphQL에서는 Union타입을 지원합니다.

'GraphQL에서 Union은 서로 다른 객체 타입을 하나의 타입으로 Reserve할 수 있다'

 

상기 이미지와 같이, 닉네임 중복이나 금칙어에 대해 객체 타입을 정의하고, 각각의 객체 타입에 대해 Union 타입의 Output을 선언할 수 있습니다.

해당 유니온 타입을 기준으로 다음과 같이 쿼리를 설계할 수 있습니다.

query {
 checkNickname(nickname: "도지사지말껄") {
 __typename
 ... on NicknameSucceed {
 nickname
 }
 ... on DuplicatedNickname {
 message
 }
 ... on PwordError {
 }

해당 쿼리를 실행하게 된다면, 유니온 타입에 정의된 대로 각각의 반환 값을 받을 수 있습니다. (56p 참고)

그런데 만약 해당 유니온 타입에 새로운 에러가 인입된다면, 기존에 사용하던 클라이언트 쿼리로는 해당 에러를 파악할 수 없습니다. on 구문을 추가해도 되지만, 확장성에 문제가 있죠.

이러한 문제를 해결하기 위해, graphQL에서는 interface를 제공합니다.

‘GraphQL에서 Interface는 타입 시스템에서 공통된 필드를 가진 객체 타입들의 집합’

일반적으로 자바에서 통용되는 바로 그 interface와 개념적으로 매우 유사하다고 생각하면 이해가 쉬울 것 같은데요. 인터페이스로 그 외 처리되는 에러에 대해 선언을 해보겠습니다.

interface BaseError {
 message: String!
}

/base error interface 예시

이렇게 설계된 인터페이스를 상속해서 각각의 타입을 선언할 수 있겠죠!

이렇게 설계된 타입으로 구현된 Union 타입은 새로 인입된 정책을 명시하지 않더라도 메시지 필드를 받기 때문에 에러를 인지할 수 있습니다.

 

💡GraphQL 사용 사례 - ‘Field Resolver’

마지막 사례는 마이 플레이스 내 ‘게시물 노출 조건’을 사례로 들고자 합니다.

다음과 같은 포스팅은 회원에게 보여질 때 정책이 있었는데요.

1. 해당 게시글이 공개일 때
2. 해당 게시글이 검수된 게시글일 때
3. 해당 게시글이 신고 받은 게시글이 아닐 때

이러한 정책을 iOS, AOS, WEB 에서 개발할 때 각각의 개발자가 해당 정책에 대해 이해하고 개발해야한다는 점에서 불편함을 가지고 있었습니다. 그리고 이렇게 개발하게 되면 실수할 확률도 더 높아지겠죠.

이러한 점을 개선하기 위해, GraphQL에서는 Field Resolver라는 함수를 제공합니다.

'Field Resolver는 데이터를 검색하거나 가공할 때 각 필드에 대한 값을 결정하는 함수'

Field resolver는 getter 함수와 유사한데요, 생성한 쿼리에 대한 Resolver를 선언하고, 해당 Resolver에서 리턴된 값을 Filed resolver에서 가공하여 반환합니다.

 

 

Rest API에서도 Field resolver와 비슷하게 구현할 수 있지만, 다음과 같은 세가지 문제점이 있습니다.

1. 필요와 상관없이 항상 계산해야 한다.
2. 필요 시 받게끔 구현하려면 파라미터 또는 엔드 포인트를 추가해야 한다.

반면 field resolver의 경우 query에서 해당 filed가 요청될 때만 실행이 되기 때문에, 퍼포먼스에 유리하다는 장점이 있습니다.

이러한 특성 덕분에, 개발 체계가 다르더라도 GraphQL에서 비즈니스 로직을 정의하여 반환값을 돌려주기 때문에, 클라이언트의 실수를 줄일 수 있다는 장점을 가지고 있습니다.

GraphQL이 주는 시사점

graphQL은 2016년 이후로 꾸준하게 인기도가 상승 중인 매력적인 쿼리언어입니다.

특히 GraphQL은 클라이언트 측에서 필요한 데이터만 요청할 수 있으며, 서버에서는 클라이언트 요청에 필요한 데이터만 제공함으로써 네트워크 트래픽을 최적화할 수 있기 때문에  데이터 요청과 응답이 매우 다양하고 복잡한 경우에 유용할 수 있습니다.
또한, GraphQL은 여러 데이터 소스를 하나의 API로 통합하기도 쉽기 때문에, MSA 전환 과정에서 다양한 데이터 소스를 통합하는데 유용할 수 있습니다.

 

1. 필요한 데이터만 가져올 수 있습니다.
   GraphQL은 클라이언트에서 요청한 필드만 가져오기 때문에, 데이터의 오버페칭(Overfetching)과 언더페칭(Underfetching) 문제를 해결할 수 있습니다. 이는 데이터 전송량을 줄이고, 네트워크 대역폭을 절약할 수 있습니다.
2. 하나의 요청으로 여러 개의 데이터를 가져올 수 있습니다.
   REST API에서는 여러 요청을 보내야 하지만, GraphQL에서는 하나의 요청으로 여러 개의 데이터를 가져올 수 있습니다. 이는 네트워크 비용을 줄이고, 성능을 향상시킵니다.
3. 타입 시스템을 제공합니다.
   GraphQL은 강력한 타입 시스템을 가지고 있습니다. 이를 통해 API의 유효성을 검증하고, 문서화를 쉽게 할 수 있습니다. 이는 API의 이해도와 유지 보수성을 향상시킵니다.