GraphQL을 도입하기 전 생각 해 볼 만한 것들

모던 브라우저의 경우 성능이 많이 좋아져서 유저가 불편할 정도의 지연은 자주 발생하지 않지만, API 통신은 네트워크 환경의 영향을 많이 받고, 데이터 크기에 따라 속도 차이가 발생할 수 있습니다. 그렇기 때문에 API통신의 로직을 설계할 때는 유저에게 보여줄 데이터를 캐싱하고, 새로 받아오는 시기를 잘 결정해야 합니다.

GraphQL 이란?

앞의 상황에서 유용하게 사용할 수 있는 GraphQL은 애플리케이션 프로그래밍 인터페이스(API)를 위한 쿼리 언어이자 서버측 런타임으로, 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선 순위를 둡니다. REST를 대체할 수 있으며 개발자가 단일 API 호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있도록 지원합니다.

---

Rest API에서의 문제

Rest API에선 요청의 목적에 맞게 엔드포인트와 응답할 데이터들을 미리 정의하고있습니다. [Get] 메서드로 유저 정보를 받아오고 싶다면, 일반적으로 도메인 끝에 'user/[userId]'같은 경로 변수를 붙여 요청을 보내게 됩니다.

만약 UI페이지 마다 유저 정보를 보여주는 방식이 다르다면

메인 화면에서는 유저의 닉네임만 보여주고,
계정 설정 화면에서는 닉네임과 이메일, 전화번호 등을 보여줘
서로 필요한 데이터의 형태가 다른 경우

API의 엔드포인트를 두개로 나눠야 할까요?
이 방식은 데이터에 포함할 필드를 유연하게 바꿀 수 없어 불필요한 필드 값까지 주고받거나 API를 여러번 호출해야하기 때문에 비효율적입니다. API 통신은 네트워크 환경의 영향을 많이 받기 때문에, 여러개의 API를 호출할 때는 횟수를 최대한 줄이는것이 좋습니다.

이러한 언더페칭, 오버페칭을 해결하고자 'GraphQL'이 나타나게 되었습니다.

GraphQL 장단점

장점

언더페칭, 오버페칭 해결이 가능하다.

GraphQL을 이용하면 클라이언트에서 필요한 데이터들만 받을 수 있습니다. (서버에서 모든 필드에 대해 어떤 데이터를 가공해서 보낼지에 대한 구현이 완료되어 있어야합니다.)

클라이언트와 서버 간 통신 오류를 줄여준다.

Rest API와 달리, 하나의 엔드포인트에서만 요청을 보내도록 되어있어 잘못된 엔드포인트에 요청을 보내는 경우가 사라집니다. API별로 엔드포인트를 지정하고 요청 객체 형태를 논의해야할 수고가 사라져 프론트엔드와 백엔드 사이의 의사소통 비용이 줄어듭니다.

단점

HTTP 캐싱이 REST보다 훨씬 복잡하다.

HTTP 통신 시 헤더 설정을 통해 데이터 캐싱이 가능합니다. Rest API 에선 각각의 엔드포인트별로 얼마 동안 캐싱해둘지 API 헤더를 통해 간단하게 지정할 수 있지만, GraphQL은 단일 엔드포인트를 사용하기 때문에 이 이점을 누리기 어렵습니다.

-> Apollo Client 라이브러리에서 캐시 옵션을 제공하기 때문에 GraphQL에서 캐싱을 활용하고싶다면 이 라이브러리를 이용하자.

에러 핸들링이 어렵다.

여러 개의 데이터를 한 번에 요청하는 경우, Rest API에서도 에러 핸들링은 굉장히 어렵다. 하지만 GraphQL에서는 항상 여러개의 데이터를 요청하는 것이 기본 전제로 하므로 더 어려워진다.

백엔드 개발자에게 오버 엔지니어링을 유발할 수 있다.

• REST API에 친숙한 개발자의 경우 GraphQL를 학습하는 데 시간이 필요합니다.
• GraphQL은 데이터 쿼리의 상당 작업을 서버측으로 옮겨 서버 개발자 작업의 복잡성이 커집니다.
• 유지 관리 가능한 GraphQL 스키마를 작성하기 위한 추가 태스크를 수행해야 합니다.

그렇기 때문에 가벼운 서비스에서는 GraphQL보단 Rest API 방식을 채택하는게 좋은 선택입니다.

결론

GraphQL을 도입하면 프론트엔드에서는 확실히 능동적으로 일을 할 수 있지만, 백엔드에서의
트레이트오프를 고려하면, 도입은 굉장히 신중하게 검토해야합니다.