GraphQL은 하나의 API 호출로 여러 소스에서 데이터를 가져올 수 있는 API용 오픈 소스 쿼리 언어입니다. 또한 기존 데이터를 사용하여 쿼리를 수행하는 서버 측 런타임 역할도 합니다. GraphQL은 완전한 API 데이터 설명을 제공하는 동시에 클라이언트에 요청된 데이터만 제공하는 것을 우선시하며, API의 확장 및 진화를 보다 쉽게 만듭니다.
GraphQL은 유연성, 속도 및 개발자를 염두에 두고 설계되었습니다. GraphQL을 사용하면 개발자는 원하는 방식으로 API를 빌드한 다음 GraphQL 사양을 사용하여 API가 클라이언트에서 작동하는지 확인할 수 있습니다.
GraphQL 쿼리의 주요 개념 중 하나는 수신하는 데이터가 예측 가능하다는 것입니다. 불필요한 코드 문자열 대신 요청한 내용만 정확히 반환됩니다. 이러한 선언적 데이터 가져오기는 대역폭이 제한적인 모바일 기기에서 특히 유용합니다. GraphQL을 사용하는 앱은 서버가 아니라 요청되고 수신되는 데이터를 제어하기 때문에 안정적이고 빠릅니다. 또한 단일 요청으로 여러 개의 요청된 항목을 한 번에 반환할 수 있으므로 느린 네트워크 연결에서도 속도가 빠릅니다.
GraphQL의 데이터 단순화를 기반으로, API는 엔드포인트 대신 유형과 필드별로 구성됩니다. 즉, 모든 데이터에 단일 엔드포인트에서 액세스할 수 있으므로 앱에서 필요한 정보만 요청할 수 있습니다. GraphQL은 운영상의 복잡성을 줄임으로써 간소화된 API 연결 솔루션 의 워크플로에 적합합니다.
2012년에 Meta(당시 Facebook)는 Facebook 모바일 애플리케이션에 충분히 강력한 데이터 가져오기 API가 필요했습니다. Lee Byron이 이끄는 Facebook은 특히 제품 디자이너와 개발자의 관점에서 데이터 가져오기를 간소화하는 방법으로 GraphQL을 개발했습니다. GraphQL은 처음에 Facebook에서 내부적으로 사용되다가 2015년에 공개적으로 출시되어 오픈 소스로 공개되었습니다. 다른 많은 오픈 소스 프로젝트의 경로를 따라 GraphQL 프로젝트는 2019년에 Linux Foundation이 호스팅하는 자체 GraphQL Foundation 으로 이전했습니다.
GraphQL은 REST 아키텍처에 대한 대안으로 설계되었습니다. 표준 REST API는 별도의 HTTP GET 요청을 통해 여러 URL에서 정보를 로드해야 합니다. GraphQL API를 사용하면 모든 데이터를 단일 POST 요청을 통해 검색합니다. REST와 GraphQL은 모두 JSON 형식의 응답을 반환하지만, GraphQL은 데이터를 간소화하고 통합하는 데 중점을 둡니다.
GraphQL은 세분화된 데이터 요청을 지원하고 클라이언트가 전송되는 정보에 대한 더 많은 제어권을 제공합니다. 클라이언트는 POST 요청의 형태로 GraphQL 쿼리를 보내고 서버는 이에 대해 JSON 형식의 응답을 반환합니다. GraphQL은 특정 애플리케이션 아키텍처가 필요하지 않고 여러 환경(통합 개발 환경[IDE] 포함)에 배포할 수 있으며 기존 API 관리 도구와 함께 사용하거나 기존 REST API를 기반으로 사용할 수 있습니다.
GraphQL의 핵심 용어는 다음과 같습니다.
GraphQL의 고유한 특징 중 하나는 응답이 쿼리의 구조(쿼리 자체는 스키마에 의해 정의됨)를 반영한다는 것입니다. 서버의 응답 형식이 완전히 예측 가능하기 때문에 클라이언트의 구문 분석이 간소화됩니다.
GraphQL의 계층적 특성은 객체 간의 관계를 따르며 계층적 사용자 인터페이스에서 잘 작동합니다. 또한 강력한 형식화이므로 각 쿼리 수준이 유형과 일치합니다. 그런 유형은 필드 집합을 정의합니다. 이는 쿼리를 완료하기 전에 설명적인 오류 메시지가 표시되는 SQL과 유사합니다.
리졸버는 GraphQL 필드, 에지, 뮤테이션, 쿼리, 구독을 데이터 소스(및 마이크로서비스)에 연결하는 핵심 아키텍처 모듈입니다.
이 GraphQL 튜토리얼 에서 AWS 데이터 소스에 대한 리졸버를 빌드하는 방법을 배울 수 있습니다.
GraphQL 쿼리를 독특하게 만드는 한 가지는 미러링된 응답입니다. API 요청의 형태와 일치할 것이라는 것을 알기 때문에 쿼리에서 반환된 데이터는 예측 가능해집니다. 반환된 데이터 형태가 클라이언트 쿼리를 따르면 서버가 단순화됩니다.
GraphQL의 주요 이점 중 하나는 REST에서 사용할 수 없는 기능을 제공하는 확장 기능이 있다는 것입니다. GraphQL의 다른 장점은 다음과 같습니다.
GraphQL 스키마는 GraphQL 애플리케이션에서 단일 진실 소스를 설정하여 모든 데이터가 설명되는 주요 위치를 제공합니다. GraphQL 스키마는 일반적으로 서버에서 정의되지만, 클라이언트는 여전히 스키마를 기반으로 데이터를 쿼리하고 쓸 수 있습니다.
REST 아키텍처에서 과도한 페칭은 빠르게 문제가 될 수 있습니다. 애플리케이션(백엔드)은 각 리소스에 대해 사용 가능한 데이터를 정의하고 클라이언트(프런트엔드)에 단일 요소만 필요한 경우에도 응답에서 모든 데이터를 반환합니다. GraphQL 호출은 한 번의 트립으로 이루어지며 클라이언트에게 과도한 페치 없이 요청된 데이터를 제공합니다.
데이터 유형이 강력하게 정의되어 있기 때문에 GraphQL에서는 클라이언트와 서버 간의 통신이 REST보다 더 명확합니다. 이 기본 구조는 GraphQL 서버를 호출하는 데 복잡한 클라이언트가 필요하지 않다는 것을 의미합니다. 자세한 내용을 알아보고 코드가 실제로 실행되는 모습을 보려면 GraphQL 공식 페이지 에서 클라이언트와 서버에 대해 읽어보세요.
API 페더레이션은 일련의 설계 원칙과 도구로, 제한된 컨텍스트 내에서 서비스를 사용자에게 일관된 API로 공개하는 동시에 해당 컨텍스트 내의 서비스가 제한 없이 진화할 수 있도록 해줍니다. GraphQL은 전체 API를 연합하고 이전 쿼리를 중단하지 않고도 발전할 수 있는 방법을 제공하며, 이는 확장 가능합니다. 이러한 확장성은 많은 기업에서 GraphQL을 사용하는 이유 중 하나입니다.
GraphQL의 내성적 특성으로 GraphQL API에서 GraphQL 스키마를 검색할 수 있습니다. 클라이언트는 사용 가능한 데이터 유형 목록을 요청할 수도 있는데, 이는 문서를 자동으로 생성하고 여러 마이크로서비스에서 스키마를 테스트하거나 검색하는 데 이상적입니다.
GraphQL을 도입하는 데에는 많은 이유가 있지만, 알아두어야 할 몇 가지 단점도 있습니다. 예를 들어, 모든 것이 즉시 사용 가능한 것은 아닙니다. 다른 사람의 API를 사용하려면 특수 라이브러리가 필요합니다. 그리고 전반적으로 GraphQL은 REST보다 더 많은 툴링 지원이 필요합니다.
REST에 비해 GraphQL의 단점은 다음과 같습니다.
REST API에 익숙한 개발자의 경우 GraphQL을 배우는 데는 시간이 더 걸립니다. 또한 워크플로도 변경될 수 있습니다. GraphQL을 사용하는 API 팀도 유지 관리 가능한 GraphQL 스키마를 작성해야 합니다. 그럼에도 불구하고, 새로 시작하는 경우 GraphQL은 요청과 응답의 구조가 동일하기 때문에 배우고 사용하기 쉽습니다.
GraphQL은 새로운 API 관리 전략을 필요로 할 수 있는 반면, REST API는 기존 API 관리 모델에 맞춰지는 경향이 있습니다. 새로운 API 관리 전략을 추가하면 전체 비용이 증가할 수 있으므로 이 점을 고려하는 것이 중요합니다.
GraphQL에서 캐싱은 REST에서보다 덜 간단합니다. REST의 경우 요청은 일반적으로 HTTP 메서드(GET, POST, PUT 또는 DELETE)를 사용합니다. 표준 GraphQL 요청은 POST이며 HTTP 수준에서 캐시할 수 없습니다. GraphQL에서 캐싱은 복잡해질 수도 있습니다. 단일 엔드포인트가 있다는 것은 엔드포인트의 URL이 다양하고 캐시할 수 없는 여러 응답을 생성한다는 것을 의미하기 때문입니다(데이터를 가져오는 데는 좋지만 캐싱에는 나쁩니다). 그러면 서버 개발자는 동일한 객체 내에서 작동하더라도 서로 다른 쿼리를 사용하게 됩니다. 즉, 많은 GraphQL 라이브러리는 기본적으로 캐싱 메커니즘을 제공합니다.