GraphQL 소개
“A query language for your API”
“당신의 API 를 위한 Query 언어” 라는 소개로 시작하는 GraphQL 은 많은 개발자들이 사용하고 있는 REST API 와 다른 개념을 가지고 있다.
GraphQL gql 은,
- API 에서 제공하는 데이터를 클라이언트 기준 필요한 데이터만 조회
- 구현 방식에 따라 단일 요청으로 더 많은 데이터 조회
- API 버전에 따른 기존 Query 영향없이 새로운 필드와 타입 추가
gql 의 특징으로,
- API 를 위한 Query 언어
- 타입 시스템을 사용한 Query 를 실행하는 서버사이드 런타임
- 특정 데이터베이스 또는 스토리지 엔진과 관계되지 않고, 기존 코드와 데이터에 의해 대체
- 데이터베이스나 플랫폼에 종속되지 않고, 네트워크 방식에도 종속되지 않음
GraphQL vs REST API
REST API 는 정의에 따라 차이가 있을 수 있겠지만, 기본적으로 URL, Method 등 활용한 API 제공하기에 많은 Endpoint 가 있을 수 밖에 없다. (e.g. GET /api/user/name, GET /api/user/address/)
그러기에, 각 API 별 데이터를 조회하는 SQL 은 달라지게 된다.
하지만, gql 은 정해진 Schema 의 타입마다 데이터베이스를 조회하는 SQL 이 달라지지만, 서버-클라이언트 간의 Endpoint 는 하나로 유지할 수 있다.
GraphQL 정의
gql은 앞서 설명한 것과 같이 서버(백엔드)에서Schema를 정의하면, 클라이언트(프론트엔드)는Schema정의에 맞춰 다양한 쿼리 조회할 수 있다.Schema정의는 보통 개발 언어에서 자주 사용하는Type (e.g. String, Int ..)으로 정의할 수 있다.
Query 정의
gql은 백엔드 개발에 대한 부담을 덜해주지만, 각Query에 대한 정의와 데이터 처리Resolver리졸버 구현은 필요하다.- 다음은
gql로 구현된 프로젝트에서 제공하는Query의 정의 방식이다.
type Query {
bookById(id: ID): Book,
bookByName(name: String): Book,
bookByIdAndName(id: ID, name: String): Book
}Schema 정의
gql의Query요청/응답에서 사용되는 정보Schema에 대한 정의를 한다.
type Book {
id: ID
name: String
author: Author
pageCount: Int
}
type Author {
id: ID
firstName: String
lastName: String
}GraphQL Query 요청/응답
gql요청하는 방식은 간단하며, 개발자가 알아보기 쉬운 명시적인 방식으로 요청한다.- 백엔드에서 정의한
Query정의대로 원하는 정보들만 요청하고 조회 응답 받을 수 있다.
Request
query {
bookById(id: "book-1") {
id
name
pageCount
author {
firstName
lastName
}
}
}Response
{
"data": {
"bookById": {
"id": "book-1",
"name": "Effective Java",
"pageCount": 416,
"author": {
"firstName": "Joshua",
"lastName": "Bloch"
}
}
}
}GraphQL 구현
gql 에 대한 이해도를 더하기 위해 그나마 익숙한 Spring F/W 기반 샘플 프로젝트를 구현해보았다.
Spring 진영에서도 gql 라이브러리를 이미 제공하고 있고,
Spring GraphQL 프로젝트는 Apollo GraphQL 라이브러리를 활용하여 더 쉽게 gql 를 이해/활용할 수 있도록 제공하고 있다.
Spring GraphQL 프로젝트의 GraphiQL
기존 REST API 개발 방식에는 비즈니스 로직 개발 외 API 문서를 작성 및 공유하는 것이다.
OpenAPI 3.0 과 같은 Swagger 문서 작성 방식을 많이 채택하지만, 그 또한 현행화 유지는 쉬운 일이 아니다.
Spring GraphQL 은 Apollo 라이브러리에서 제공해주는 Apollo Sandbox 를 통해서 서버에서 정의한 Query, Schema 를 한눈에 확인 가능하다.
정리
GraphQL 은 확실히 기존 많이 사용하는 REST API 방식과는 개발 방식에 대한 차이가 많이 있는 것 같다.
백엔드 개발에 대한 부담이 많이 줄어들 것 같지만, 과연 상용 서비스의 수많은 요구 사항에 대한 비즈니스 로직을 얼마만큼 잘 소화하고,
높은 개발 생산성을 제공할 수 있을지에 대한 확고함은 생기진 않았다. (아직 제대로된 개발을 하지 않은 이유가 제일 크겠지만..🤔)
프론트엔드 개발 부분에서도 Flux 아키텍처 기반 구현 방식으로 높은 러닝-커브 때문에 쉽게 접근은 어렵다는 글이 많은 것 같다.
하지만 모든 기술 스펙이 그러하듯이 러닝-커브는 있을 수 있지만,
개발자 친화적인 방식으로 개발을 쉽고, 간단하고, 빠르게 할 수 있도록 새로운 패러다임을 제시하는 것 같다.
그런 측면에서 GraphQL 또한 적절한 상황과 서비스에 접목하면 높은 개발 생산성과 우수한 성능을 제공할 수 있는 기술 스펙이라 생각된다.
