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년에 공개적으로 릴리스되어 오픈 소스화되었습니다. 다른 많은 오픈 소스 프로젝트의 궤적을 따라 2019년에 GraphQL 프로젝트는 Linux Foundation에서 호스팅하는 자체 GraphQL Foundation으로 이전했습니다.
GraphQL은 REST 아키텍처의 대안으로 설계되었습니다. 표준 REST API는 별도의 HTTP GET 요청을 통해 여러 URL에서 정보를 로드해야 합니다. 하지만 GraphQL API를 사용하면 단일 POST 요청을 통해 모든 데이터를 가져옵니다. REST와 GraphQL이 모두 JSON 형식의 응답을 반환하지만 GraphQL은 데이터 간소화 및 통합에 중점을 둡니다.
GraphQL은 세분화된 데이터 요청을 지원하며 클라이언트가 전송되는 정보를 더욱 잘 제어할 수 있도록 합니다. 클라이언트는 서버가 JSON 형식의 응답을 반환하는 POST 요청 형식으로 GraphQL 쿼리를 보냅니다. GraphQL은 특정 애플리케이션 아키텍처가 필요하지 않으며 여러 환경(통합 개발 환경[IDE] 포함)에 배포할 수 있고 기존 API 관리 도구와 함께 또는 기존 REST API 위에서 사용할 수 있습니다.
GraphQL 내에서 사용되는 몇 가지 주요 용어는 다음과 같습니다.
GraphQL의 고유한 기능 중 하나는 응답이 쿼리의 구조(스키마에 의해 정의됨)를 반영한다는 것입니다. 서버의 응답 형식을 완전히 예측할 수 있기 때문에 클라이언트에 대한 구문 분석이 간소화됩니다.
GraphQL의 계층적 특성은 개체 간의 관계를 따르며 계층적 사용자 인터페이스에서 잘 작동합니다. 또한 강력하게 유형화되어 있으므로 각 쿼리 수준이 하나의 유형과 일치합니다. 그 다음, 이러한 유형이 필드 집합을 정의하며, 이는 하나의 쿼리를 완료하기 전에 설명 오류 메시지가 표시되는 SQL과 유사합니다.
처리기는 GraphQL 필드, 엣지, 변이, 쿼리 및 구독을 데이터 소스(및 마이크로서비스)에 연결하는 주요 아키텍처 모듈입니다.
이 GraphQL 자습서에서 AWS 데이터 소스용 처리기를 구축하는 방법을 배울 수 있습니다.
GraphQL 쿼리를 고유하게 만드는 한 가지는 미러링된 응답입니다. 쿼리에서 반환되는 데이터는 API 요청의 형태와 일치한다는 것을 알기 때문에 예측이 가능해집니다. 반환된 데이터 형태가 클라이언트 쿼리를 따르는 경우 서버가 단순화됩니다.
GraphQL의 주요 이점 중 하나는 REST에서 사용할 수 없는 기능을 제공하기 위해 확장할 수 있다는 점입니다. GraphQL의 다른 장점은 다음과 같습니다.
GraphQL 스키마는 GraphQL 애플리케이션에서 신뢰할 수 있는 단일 소스를 설정하여 모든 데이터가 설명되는 기본 위치를 제공합니다. GraphQL 스키마는 일반적으로 서버에서 정의되지만 클라이언트는 스키마에 따라 계속 데이터를 쿼리하고 쓸 수 있습니다.
REST 아키텍처에서 오버페칭은 빠르게 문제가 될 수 있습니다. 애플리케이션(백엔드)은 클라이언트(프론트엔드)에 단일 요소만 필요한 경우에도 각 리소스에 사용할 수 있는 데이터를 정의하고 응답 시 모든 데이터를 반환합니다. GraphQL 호출은 단일 트립에서 이루어지며 오버페칭 없이 요청된 데이터를 클라이언트에게 제공합니다.
데이터 유형이 강력하게 정의되어 있기 때문에 클라이언트와 서버 간의 통신은 REST보다 GraphQL에서 훨씬 명확합니다. 또한 이러한 기본 구조는 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 관리 전략을 추가하면 전체 비용이 증가할 수 있기 때문입니다.
캐싱은 요청이 일반적으로 HTTP 메서드(GET, POST, PUT 또는 DELETE)를 사용하는 REST보다 GraphQL에서 덜 간단합니다. 표준 GraphQL 요청은 HTTP 수준에서 캐시할 수 없는 POST입니다. 또한 단일 엔드포인트가 있다는 것은 엔드포인트의 URL이 캐시할 수 없는 여러 가지 다양한 응답을 생성(데이터 가져오기에는 적합하지만 캐싱에는 부적합)한다는 것을 의미하므로 GraphQL에서 캐싱이 복잡해질 수 있습니다. 그러면 서버 개발자는 동일한 개체 내에서 작동하더라도 서로 다른 쿼리를 사용하게 됩니다. 하지만 많은 GraphQL 라이브러리가 기본으로 캐싱 메커니즘을 제공하고 있다는 것은 분명한 사실입니다.