새로운 API 표준
GraphQL은 REST API보다 효율적이고 강력한 새로운 API 표준이다.
Facebook에서 개발하고 오픈소스로 제공했다.
REST API보다 효율적이고 강력한 API 표준이라는 말이 어떤 이유에서 인지 알아보기 위해서, GraphQL이 해결하려고 하던 문제와 GraphQL이 해결하고자 했던 핵심적인 내용이 어떤 것인지 밑에서 알아보았다.
GraphQL은 API용 Query Language다
내 생각에 GraphQL의 핵심 개념은 바로 이 부분이라고 생각한다. 오늘날 대부분의 애플리케이션은 데이터가 데이터베이스가 저장된 서버에서 데이터를 가져와야 한다. 즉, 서버에서 제공하는 고정 데이터를 받는 방법 외에 클라이언트 측에서 원하는 데이터를 선언적으로 불러올 수 있는 방법이 없었다.
Query Language가 무엇인가
질의어(영어: query language)는 데이터베이스와 정보 시스템에 질의를 할 수 있게 하는 고급 컴퓨터 언어이다.
- 위키백과
Query language라고 하면 가장 먼저 떠오르는 것이 아마 SQL일 것이라고 생각한다. 특정 원하는 데이터를 얻기 위해 데이터베이스에 조회를 할때 SQL을 사용하면 원하는 데이터를 얻어낼 수 있다.
위의 정의 처럼 GraphQL도 Query language인데, {클라이언트-서버-데이터베이스}의 기본 3 Tier Architecture라고 가정했을때
- GQL은 클라이언트와 API 사이의 Query language
- SQL은 서버와 데이터베이스 사이의 Query language
라고 이해할 수 있다.
즉, 서버가 데이터베이스에서 SQL을 통해 데이터를 질의하는 것과 마찬가지로, 클라이언트가 API에게 특정 엔드포인트를 통해 고정된 데이터(기존 REST API)를 받는 것이 아니라 API에게 원하는 데이터를 질의해서 가져올 수 있게끔 한 것이다.
왜 Facebook은 이것을 만들었을까?
Facebook은 2015년에 오픈 소스로 GraphQL을 공개하기 전에, 2012년부터 기본 모바일 앱에서 GraphQL을 사용하기 시작했다고 한다. 재밌는 것은 Netflix와 Coursera와 같은 회사도 유사한 아이디어를 연구하고 있었다는 것이다. 기존 REST API의 불편한 점들을 많이 공감하고 있었다는 의미인데, 그들이 해결하고자 했던 문제가 무엇일까.
1. 모바일 사용량 증가로 인해 효율적인 데이터 로딩이 필요하다.
-> REST API의 개념이 나왔을 때 클라이언트 애플리케이션이 저전력의 장비들이 많지 않았으나, 모바일 사용이 증가하게 되면서 필수불가결하게 네트워크를 통해 전송해야 하는 데이터의 양을 최소화할 필요성이 필요했다. 즉, 고정 데이터를 전송받는 방식이 아닌 선언적으로 데이터를 불러오는 것이 필요했다.
2. 프론트엔드 프레임워크 및 플랫폼이 다양해졌다.
같은 서비스를 모바일, 웹, TV, 스마트워치 등으로 보는 시대가 되었다. 실제로 모바일 앱에서 보는 UI와 웹사이트를 통해 보는 UI, TV에서 보는 UI, 스마트워치에서 보내는 UI가 모두 다른데 이것을 일일히 대응할 수 있는 하나의 API를 구축하고 유지 관리하는 데에는 비용이 너무 많이 들게 되었다. GraphQL은 각각의 프론트엔드 클라이언트가 필요한 데이터에 정확하게 액세스 할 수 있게 한다.
3. 빠른 개발 & 빠른 기능 개발 기대
지속적 배포는 많은 회사들의 표준이 되었고, 디자인 또는 기능 업데이트가 빈번하게 일어나는 시대가 되었다. REST API를 사용하면 클라이언트 측의 디자인 변경 혹은 요구 사항에 따라 서버에서 데이터를 노출하는 방식을 계속 수정해야 하는 경우가 빈번하게 생기게 되었다. GraphQL은 클라이언트 자체에서 필요한 데이터를 요청하기 때문에 데이터 노출 방식을 변화할 이유가 없다.
마무리
이전 글에서 적은 문제점 글에서 GraphQL에 대한 개요와 만들어진 이유에 대한 내용이 부족한 것 같아 이 글을 작성하게 되었다. 개념적으로 느껴지는 장점들이 확실하게 보이는데, 우려되는 점은 REST API로 접근하던 방식이 익숙해서 쿼리를 보내 원하는 데이터에 접근한다는 것 자체가 어색하기는 하다. 이번에 GraphQL을 사용해 Hackernews를 클론하면서 클라이언트와 백엔드를 모두 직접 작성해보려고 한다.
