GraphQL 사용 후기

GraphQL은 2012년 페이스북에서 개발해서 2015년에 공개적으로 발표했습니다. 여러 개발자들 사이에서 자주 입에 오르내리고 있고, 한번 사용해보면 REST API를 더 이상 사용하지 않게된다는 등의 좋은 평가가 많아 알게되었습니다.

그러다 최근 타 회사에서 개발되어있던 웹 프로젝트 소스를 이어받아 유지보수 업무를 받게되었는데 GraphQL이 사용되고 있었던 겁니다. 반 강제적으로 GraphQL을 사용해야 하는 상황이 된거죠. 개발이 끝난 지금 GraphQL을 사용했던 후기를 공유합니다.

서비스 내에서 GraphQL의 위치

GraphQL은 쿼리 언어입니다. 쿼리 언어라고 하면 흔히 SQL을 떠올리게 되는데요. 그러나 데이터베이스로 보내는 요청에 대한 규격인 SQL 쿼리와는 달리 GraphQL은 클라이언트에서 서버로 보내는 요청에 대한 규격입니다. 그렇기에 SQL과 같은 데이터베이스 쿼리 보다는 REST API와 비교하는 것이 더 바람직합니다.

REST API 와의 차이

사실 GraphQL과 REST API의 근본적인 네트워크 요청 방식에는 차이가 없습니다. 실제로 클라이언트에서 보내는 GraphQL 요청을 개발자 도구로 확인해보면 POST 요청으로 나오는 것을 확인할 수 있습니다. 그냥 POST로 쿼리를 보낸다고 봐도 무방하죠. 다만 이를 처리하는 과정에서 보통의 REST API과 구조적인 차이가 나게됩니다.

모든 요청을 하나의 Endpoint로

목적과 기능에 따라 매번 새로운 Endpoint를 생성하는 REST API와 달리 GraphQL은 하나의 Endpoint 만을 갖습니다. 해당 Endpoint에서 어떠한 기능을 수행할지는 클라이언트에서 보내는 쿼리에 따라 달라집니다 (일반적으로 Query 와 Mutation 방식으로 나뉩니다).

받아오는 데이터 구조를 클라이언트에서 지정

요청에 대한 응답의 규격을 서버에서 지정한대로만 내어주는 REST API와 다르게 GraphQL에서는 클라이언트에서 규격을 정하고, 서버에서 그 규격에 맞춰서 가져다줍니다.

query {
  author(id: 1) {
    firstName
    posts {
      title
    }
  }
}

GraphQL 쿼리 예시: author 쿼리에 대해 응답 구조를 중괄호 내부에 정의합니다.

사용 후기

기존에 사용하던 REST API와 비교했을 때 장단점이 뚜렷하다고 느껴집니다.

장점

네트워크 요청 최적화에 적합

• 클라이언트에서 원하는 데이터 구조를 직접 지정하여 필요 없는 데이터는 제외할 수 있습니다 (Overfetching 해결에 용이함). 또한 REST API 에서 여러 번 이뤄져야 할 요청을 하나로 묶을 수 있어 요청 수를 줄일 수 있습니다.

확장성

• 하나의 Endpont만 사용함으로 유지보수가 편해지고 소스코드의 구조가 좀 더 간소화되는 효과가 있습니다.

편리한 개발 환경

• GraphQL 서버 개발 라이브러리에 개발용 페이지가 포함되어 있습니다. 사용할 수 있는 쿼리, 데이터 타입이 잘 정의되어 보여지고 쿼리 테스트까지 가능하기에 규격을 공유하기 편합니다.

단점

높은 진입장벽

• 클라이언트를 위해 다 차려진 REST API 규격에서 벗어나 데이터의 구조를 직접 다뤄야 한다는 것은 큰 진입장벽이 될 수 있습니다. 개발의 난이도를 떠나서도 GraphQL 도입은 많은 구조적 변화를 초래합니다.

캐싱

• 하나의 URL만 사용하기에 캐싱을 구현하는데 제약사항이 생깁니다. 캐싱이 필요한 경우 클라이언트에서 자체적으로 구현해야 합니다.

파일 전송

• 파일 전송과 같은 특수한 요청에 대해 완성된 명세가 존재하지 않습니다. 불가능하진 않지만 규격에서 벗어난 코드를 작성해야 합니다.