GraphQL은 클라이언트가 애플리케이션 프로그래밍 인터페이스(API)와 상호 작용하는 방식을 지정하는 오픈 소스 쿼리 언어이자 서버 측 런타임입니다.
GraphQL은 표현 상태 전송 (REST) 및 RESTful API에 대한 효율적이고 유연한 대안을 제공하며 REST의 일부 제한 사항을 해결합니다. 예를 들어, 단일 쿼리로 리소스를 보다 정확하게 타기팅할 수 있는 기능을 제공합니다.
GraphQL은 직관적인 구문을 사용하여 클라이언트가 많은 매개변수가 있는 복잡한 엔드포인트에 액세스하는 대신 단일 GraphQL 쿼리를 API로 전송하고 필요한 데이터를 정확하게 수신할 수 있도록 해줍니다. 이렇게 보다 효율적인 데이터 가져오기를 통해 성능과 개발자의 사용 편의성을 개선할 수 있습니다.
이러한 기능 덕분에 GraphQL은 프론트엔드 요구 사항이 빠르게 변화하는 복잡한 환경에서 API를 구축하는 데 특히 유용합니다. REST나 GraphQL API는 본질적으로 우수하지 않습니다. 이들은 다양한 작업에 적합한 다양한 툴입니다.
2010년대 초, Facebook은 엄청난 성장과 변화를 겪고 있었습니다. 그러나 사용자 기반이 증가하고 모바일 앱 환경이 점점 더 복잡해짐에 따라 필요한 모든 쿼리 데이터를 가져오기 위해 여러 엔드포인트를 여러 번 왕복해야 했던 기존의 RESTful 접근 방식은 더 이상 지속가능하지 않게 되었습니다.
REST 및 RESTful API는 복잡한 데이터 기반 사용자 인터페이스를 처리하는 데 적합하지 않았으며, 특히 데이터 요금제가 제한적이거나 비싼 모바일 사용자의 경우 지연 문제가 자주 발생하여 데이터 비효율성을 종종 겪고는 했습니다.
Facebook 엔지니어들은 이러한 문제에 대응하기 위해 단일 페이지 애플리케이션 플랫폼인 React와 함께 GraphQL을 개발하여 2015년에 오픈 소스 솔루션으로 공개했습니다. 그리고 2018년, Facebook은 이 GraphQL 서비스를 AWS, Gatsby, Intuit, IBM 등의 회원사로 구성된 GraphQL 재단으로 이전했습니다.
GraphQL 아키텍처의 선언적 데이터 가져오기 기능은 데이터 처리 및 프로세스에서 각각 고유한 역할을 하는 주요 구성 요소와 프로세스를 중심으로 이루어집니다.
여기에는 다음이 포함됩니다.
GraphQL은 모든 데이터 유형이 GraphQL 스키마 정의 언어(SDL)로 기록되는 강력한 유형 시스템을 사용합니다. 형식화된 스키마는 API에서 쿼리할 수 있는 데이터 유형은 물론 사용자가 사용할 수 있는 작업과 유형 간의 관계를 지정합니다.
즉, API의 기능과 클라이언트가 상호 작용할 수 있는 데이터의 형태를 정의합니다. 이 스키마의 구성에 따라 궁극적으로 API를 사용할 수 있는 방법이 결정됩니다. 쿼리가 들어오면 스키마는 요청 유효성 검사에 사용되며 GraphQL API는 검증된 쿼리만 실행합니다.
스키마의 각 필드는 데이터를 채우고 필드 집합에 대한 응답을 결정하는 리졸버의 지원을 받습니다. 리졸버는 데이터베이스, 클라우드 서비스 또는 거의 모든 다른 소스에서 데이터를 검색할 수 있으며, GraphQL 작업(예: 쿼리, 변경 또는 구독)을 데이터로 변환하기 위한 지침을 제공합니다.
쿼리 필드가 시작되면 시스템은 다음 값을 생성하기 위해 해당 리졸버에 대한 호출을 생성합니다. 필드가 스칼라 값(예: 문자열 또는 숫자)을 생성하는 경우 실행이 완료됩니다. 필드가 객체 값을 생성하는 경우 쿼리에는 해당 객체에 대한 필드가 더 포함됩니다. 이 프로세스는 스칼라 필드만 남을 때까지 계속됩니다.
또한 리졸버는 데이터 서식을 쉽게 지정하고 시스템이 다양한 데이터 소스의 정보를 연결할 수 있도록 도와줍니다.
데이터 쿼리는 클라이언트가 GraphQL 서버에 보내는 요청으로, 클라이언트가 가져올 데이터를 지정합니다. 쿼리는 쿼리 유형으로 정의되며, 이는 클라이언트가 서버에 대해 실행할 수 있는 모든 요청에 대한 최상위 진입점을 정의하는 코드의 특수 개체입니다. 또한 각 쿼리 유형은 각 진입점의 이름과 반환 유형을 정의합니다.
쿼리가 들어오면 GraphQL은 스키마 정의에 대해 쿼리의 유효성을 검사하고 쿼리가 유효하다고 가정하면 실행합니다. 쿼리 구조는 일반적으로 응답 데이터의 구조를 반영하여 데이터 요구 사항을 명시적이고 예측 가능하게 만듭니다.
변이는 서버에서 데이터를 생성, 업데이트 또는 삭제하는 GraphQL 작업입니다. 이는 RESTful API의 POST, PUT, PATCH 및 DELETE 작업과 유사합니다. 사용자는 인증없이 일부 쿼리에 액세스할 수 있지만, 변이를 위해서는 항상 인증이 필요합니다(예: API 토큰 사용).
쿼리가 작동하는 방식과 유사하게 GraphQL 변이는 스키마와 해당 정의에 대해 유효성이 검사됩니다. 변이의 유효성이 검사되고 시작되면 서버는 JSON 응답을 반환합니다.
GraphQL API가 보다 효율적이고 유연한 대안으로 떠오르고 있지만, REST는 오랫동안 API 아키텍처의 표준으로 사용되어 왔습니다. REST는 네트워크 하이퍼미디어 애플리케이션을 위한 구조화된 아키텍처 스타일로, 캐시 가능한 상태 비저장 클라이언트-서버 통신 프로토콜(일반적으로 HTTP)을 사용하도록 설계되었습니다.
GraphQL과 REST 중 하나를 선택하는 것은 주로 어떤 툴이 현재 작업에 가장 적합한지 결정하는 것입니다. GraphQL과 REST 모두 클라이언트가 서버와 통신하고 데이터를 요청할 수 있도록 지원하지만 큰 차이점이 있으며, 이 차이점을 들여다보면 GraphQL 시스템의 빠른 확산 이유에 대해 알 수 있습니다.
REST API는 리소스(예: 클라이언트가 액세스할 수 있는 모든 유형의 객체, 데이터 또는 서비스)를 중심으로 설계되었으며 각 리소스에 대해 서로 다른 엔드포인트(URL)를 갖는 방식으로 작동합니다. 또한 고정된 데이터 구조를 사용하여 클라이언트에 제공하는 리소스의 형태와 크기를 결정합니다.
클라이언트가 리소스를 요청하면 서버는 해당 리소스와 관련된 모든 데이터가 포함된 전체 데이터 세트를 다시 보냅니다. 클라이언트가 데이터의 하위 집합만 필요한 경우에도 모든 데이터를 수신하지만(오버 페칭), 여러 리소스에 걸쳐 있는 데이터가 필요한 경우 초기 요청에서 데이터를 제대로 검색하지 못해 여러 번 API 호출을 수행해야 합니다(언더 페칭).
반면 GraphQL은 데이터에 대한 완전하고 이해하기 쉬운 설명을 제공하는 단일 엔드포인트를 사용합니다. GraphQL 쿼리는 리소스 속성에 액세스하고 리소스 간의 참조를 추적할 수 있습니다. 이를 통해 클라이언트는 단일 API 요청 페이로드에서 필요한 모든 데이터를 가져오고 오버페칭 및 언더페칭 문제를 방지할 수 있습니다.
RESTful 아키텍처에서는 데이터 구조를 변경할 때 사용자의 시스템 오류와 서비스 중단을 방지하기 위해 팀에서 API를 버전 관리해야 하는 경우가 많습니다.
REST 아키텍처의 경우 개발자는 구조를 변경할 때마다 새로운 엔드포인트를 만들어야 하므로 API 버전이 여러 개가 되고 유지 관리 프로세스가 복잡해집니다.
GraphQL은 클라이언트가 쿼리에서 요구 사항을 지정할 수 있기 때문에 버전 관리가 필요 없습니다. 새 필드가 서버에 추가되어도 해당 필드가 필요하지 않은 클라이언트는 영향을 받지 않습니다. 반대로 필드가 더 이상 사용되지 않는 경우 클라이언트는 쿼리를 업데이트할 때까지 필드를 계속 요청할 수 있습니다.
REST API는 HTTP 상태 코드를 사용하여 요청의 상태/성공을 표시합니다. 각 상태 코드에는 특정한 의미가 있습니다. 성공적인 요청은 200 상태 코드를 반환하지만, 클라이언트 오류는 일반적으로 400 상태 코드를, 서버 오류는 일반적으로 500 상태 코드를 반환합니다.
GraphQL은 오류를 다른 방식으로 처리합니다. 쿼리가 들어오면 GraphQL은 스키마 정의에 대해 쿼리의 유효성을 검사하고 쿼리가 유효하다고 가정하면 실행합니다. 오류는 HTTP 상태 코드를 사용하여 전달되지 않고 시스템이 데이터와 함께 응답 본문에 오류를 전달합니다.
이 방식에서는 클라이언트가 응답 본문을 구문 분석하여 요청이 성공했는지 확인해야 하므로 GraphQL API 디버깅이 다소 까다로울 수 있습니다.
REST에는 실시간 업데이트에 대한 기본 지원 기능이 없습니다. 웹 또는 모바일 애플리케이션에 REST API를 사용한 실시간 기능이 필요한 경우 개발자가 일반적으로 롱폴링(클라이언트가 서버에 새 데이터를 반복적으로 폴링하는 방식), 서버 전송 이벤트 및 웹소켓과 같은 기술을 구현해야 하므로 애플리케이션이 더 복잡해질 수 있습니다.
그러나 GraphQL에는 구독을 사용한 실시간 업데이트에 대한 기본 제공 지원이 포함되어 있습니다. 구독은 서버에 대한 지속적인 연결을 유지하기 때문에 특정 이벤트가 발생할 때마다 서버가 클라이언트에 업데이트를 푸시하고 클라이언트가 관련 API 데이터를 최신 상태로 유지할 수 있습니다.
REST 에코시스템은 개발자가 사용할 수 있는 다양한 툴, 라이브러리, 프레임워크 및 튜토리얼로 잘 구축되어 있습니다. 하지만 REST API로 작업하려면 여러 엔드포인트를 탐색하고 각 API의 고유한 규칙 및 패턴을 파악해야 하는 경우가 많습니다.
GraphQL은 비교적 최근에 도입되었지만, GraphQL 에코시스템은 도입 이후 프론트엔드 및 백엔드 서비스 개발에 사용할 수 있는 다양한 툴과 라이브러리를 통해 비약적으로 성장해 왔습니다.
GraphiQL, Apollo Studio, GraphQL Playground와 같은 툴은 GraphQL API를 탐색하고 테스트할 수 있는 강력한 브라우저 내 통합 개발 환경(IDE)을 제공합니다. 또한 GraphQL은 클라이언트 측 개발을 간소화할 수 있는 코드 생성을 강력하게 지원합니다.
REST API는 ETag 및 마지막으로 수정된 헤더와 같은 HTTP 캐싱 메커니즘에 기반하고 있습니다. 캐싱 전략은 효과적이지만 구현하기 복잡할 수 있으며 모든 사용 사례에 대해 성능을 일관되게 최적화하지 못할 수도 있습니다.
GraphQL API는 쿼리의 동적 특성으로 인해 캐시하기가 더 어려울 수 있습니다. 그러나 지속 쿼리, 응답 캐싱 및 서버 측 캐싱을 사용하면 어려움을 완화하고 GraphQL 아키텍처에 효율적인 캐싱 전략을 제공할 수 있습니다.
GraphQL이 GraphQL 재단으로 전환된 이후 개발자들은 JavaScript, Python, Ruby, PHP 등 다양한 프로그래밍 언어의 구현을 만들어 왔습니다. 또한 Github, Pinterest, Paypal, Shopify, Airbnb 등 수많은 기업에서 GraphQL API를 도입하여 더 많은 고객이 데이터 사양을 간소화하고, 과도하거나 부적절한 네트워크 데이터 전송을 줄이며, 전반적인 데이터 가져오기 기능을 개선할 수 있게 되었습니다.1
뿐만 아니라, 기업과 개발자들은 GraphQL 아키텍처의 오픈 페더레이션을 추진하고 있습니다. 현재 진행 중인 GraphQL 페더레이션은 별도의 GraphQL 서비스를 단일 GraphQL API로 통합하여 모든 기본 백엔드 데이터의 진입점 역할을 하고 단일 요청 데이터 가져오기를 용이하게 하고 있습니다. 그러나 현재 페더레이션 구현 기능은 특정 공급업체에서만 독점 제공되고 있습니다.
이에 대한 대응 방안으로 GraphQL 지지자들은 GraphQL 전용 집계 대신 GraphQL API와 비 GraphQL API 모두에서 데이터 취합을 용이하게 하는 민주화된 페더레이션을 지지하고 있습니다.2
무료 평가판을 통해 IBM API Connect를 사용해 보거나 IBM 전문가에게 연락하여 요구 사항을 논의해 보세요. API 관리를 최적화할 준비가 되었거나 더 자세히 알아보고 싶으시다면, IBM이 디지털 혁신을 이루도록 도와드립니다.
AI 기반 솔루션을 통해 통합 프로세스의 완전한 잠재력을 활용하세요. 시작하려면 전문가와의 상담을 예약하거나 제품 설명서를 살펴보세요.
IBM MQ의 안전한 고성능 메시징 솔루션으로 비즈니스를 강화하세요. IBM MQ를 통해 운영을 혁신하는 방법을 알아보고 싶다면 무료 평가판을 시작하거나 IBM 전문가와 상담하세요.
크기와 거리에 관계없이 파일을 더욱 빠르고 안전하게 전송하세요. 지금 IBM Aspera를 사용하여 초고속 효율성으로 데이터 워크플로를 간소화하세요.
하이브리드 환경 전반에서 통합을 현대화하기 위한 완벽한 솔루션을 구현하여, 팀이 애플리케이션 배포를 가속화하는 동시에 비용과 복잡성을 줄일 수 있도록 합니다.
IT 인프라 전반의 확장성, 현대화, 원활한 통합을 최적화하도록 설계된 IBM의 하이브리드 클라우드 솔루션으로 디지털 혁신을 간소화하세요.
IBM Cloud Infrastructure Center는 IBM zSystems 및 IBM LinuxONE에서 프라이빗 클라우드의 인프라를 관리하기 위한 OpenStack 호환 소프트웨어 플랫폼입니다.
1 IBM acquires GraphQL startup StepZen to step up its game in API Management, TechCrunch, 2023년 2월 8일
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 2023년 11월 16일
IBM web domains
ibm.com, ibm.org, ibm-zcouncil.com, insights-on-business.com, jazz.net, mobilebusinessinsights.com, promontory.com, proveit.com, ptech.org, s81c.com, securityintelligence.com, skillsbuild.org, softlayer.com, storagecommunity.org, think-exchange.com, thoughtsoncloud.com, alphaevents.webcasts.com, ibm-cloud.github.io, ibmbigdatahub.com, bluemix.net, mybluemix.net, ibm.net, ibmcloud.com, galasa.dev, blueworkslive.com, swiss-quantum.ch, blueworkslive.com, cloudant.com, ibm.ie, ibm.fr, ibm.com.br, ibm.co, ibm.ca, community.watsonanalytics.com, datapower.com, skills.yourlearning.ibm.com, bluewolf.com, carbondesignsystem.com