게시일: 2023년 12월 8일
기고자: Chrystal R. China, Michael Goodwin
GraphQL은 클라이언트가 애플리케이션 프로그래밍 인터페이스(API)와 상호 작용하는 방식을 지정하는 오픈 소스 쿼리 언어이자 서버 측 런타임입니다.
여러 매개변수가 있는 복잡한 엔드포인트에 액세스하는 대신 한 줄 또는 몇 줄로 API 요청을 할 수 있는 직관적인 구문을 사용하는 GraphQL 기술을 사용하면 API 쿼리를 쉽게 생성하고 응답할 수 있습니다. GraphQL은 기존의 RESTful 아키텍처에서 업그레이드된 아키텍처입니다.
2010년대 초, Facebook은 엄청난 성장과 변화를 겪고 있었습니다. 그러나 사용자 기반이 증가하고 모바일 앱 환경이 점점 더 복잡해짐에 따라 필요한 모든 쿼리 데이터를 가져오기 위해 여러 엔드포인트를 여러 번 왕복해야 했던 기존의 RESTful 접근 방식은 더 이상 지속가능하지 않게 되었습니다.
REST(Representational State Transfer) 및 RESTful API는 복잡한 데이터 기반 사용자 인터페이스를 처리하는 데 적합하지 않았으며, 특히 데이터 요금제가 제한적이거나 비싼 모바일 사용자의 경우 지연 문제가 자주 발생하여 데이터 비효율성을 종종 겪고는 했습니다.
Facebook 엔지니어들은 이러한 문제에 대응하기 위해 단일 페이지 애플리케이션 플랫폼인 React와 함께 GraphQL을 개발하여 2015년에 오픈 소스 솔루션으로 공개했습니다. 그리고 2018년, Facebook은 이 GraphQL 서비스를 AWS, Gatsby, Intuit, IBM 등의 회원사로 구성된 GraphQL 재단으로 이전했습니다.
응답성이 뛰어난 GraphQL API를 통해 더 적은 코드를 작성하면서 데이터 사일로를 허무는 방법을 알아보세요.
IBM API Connect, 최고의 우수성으로 명성을 떨치다
GraphQL 아키텍처의 선언적 데이터 가져오기 기능은 데이터 처리 및 프로세스에서 각각 고유한 역할을 하는 주요 구성 요소와 프로세스를 중심으로 이루어집니다.
해당 AI 어시스턴트는 다음과 같습니다.
GraphQL은 모든 데이터 유형이 GraphQL 스키마 정의 언어(SDL)로 기록되는 강력한 유형 시스템을 사용합니다. 형식화된 스키마는 API에서 쿼리할 수 있는 데이터 유형은 물론 사용자가 사용할 수 있는 작업과 유형 간의 관계를 지정합니다. 즉, API의 기능과 클라이언트가 상호 작용할 수 있는 데이터의 형태를 정의합니다.
스키마의 각 필드는 데이터를 채우고 필드 집합에 대한 응답을 결정하는 리졸버의 지원을 받습니다. 리졸버는 데이터베이스, 클라우드 서비스 또는 거의 모든 다른 소스에서 데이터를 검색할 수 있으며, GraphQL 작업(예: 쿼리, 변경 또는 구독)을 데이터로 변환하기 위한 지침을 제공합니다.
쿼리 필드가 실행되면 시스템은 다음 값을 생성하기 위해 해당 리졸버에 대한 호출을 생성합니다. 필드가 스칼라 값(예: 문자열 또는 숫자)을 생성하는 경우 실행이 완료됩니다. 필드가 객체 값을 생성하는 경우 쿼리에는 해당 객체에 대한 필드가 더 포함됩니다. 이 프로세스는 스칼라 필드만 남을 때까지 계속됩니다.
또한 리졸버는 데이터 서식을 쉽게 지정하고 시스템이 다양한 데이터 소스의 정보를 연결할 수 있도록 도와줍니다.
데이터 쿼리는 클라이언트가 GraphQL 서버에 보내는 요청으로, 클라이언트가 가져올 데이터를 지정합니다. 쿼리가 들어오면 GraphQL은 스키마 정의에 대해 쿼리의 유효성을 검사하고 쿼리가 유효하다고 가정하면 실행합니다. 쿼리 구조는 일반적으로 응답 데이터의 구조를 반영하여 데이터 요구 사항을 명시적이고 예측 가능하게 만듭니다.
변이는 서버에서 데이터를 생성, 업데이트 또는 삭제하는 GraphQL 작업입니다. 이는 RESTful API의 POST, PUT, PATCH 및 DELETE 작업과 유사합니다.
쿼리가 작동하는 방식과 유사하게 GraphQL 변이는 스키마와 해당 정의에 대해 유효성이 검사됩니다. 변이의 유효성이 검사되고 실행되면 서버는 JSON 응답을 반환합니다.
GraphQL API가 보다 효율적이고 유연한 대안으로 떠오르고 있지만, REST 및 RESTful은 오랫동안 API 아키텍처의 표준으로 사용되었습니다. REST API는 네트워크 하이퍼미디어 애플리케이션을 위한 구조화된 아키텍처 스타일로, 캐시 가능한 상태 비저장 클라이언트-서버 통신 프로토콜(일반적으로 HTTP)을 사용하도록 설계되었습니다.
GraphQL과 REST 모두 클라이언트가 서버와 통신하고 데이터를 요청할 수 있도록 지원하지만 큰 차이점이 있으며, 이 차이점을 들여다보면 GraphQL 시스템의 빠른 확산 이유에 대해 알 수 있습니다.
REST API는 리소스(예: 클라이언트가 액세스할 수 있는 모든 유형의 객체, 데이터 또는 서비스)를 중심으로 설계되었으며 각 리소스에 대해 서로 다른 엔드포인트(URL)를 갖는 방식으로 작동합니다. 또한 고정된 데이터 구조를 사용하여 클라이언트에 제공하는 리소스의 형태와 크기를 결정합니다.
클라이언트가 리소스를 요청하면 서버는 해당 리소스와 관련된 모든 데이터를 보냅니다. 클라이언트가 데이터의 하위 집합만 필요한 경우에도 모든 데이터를 수신하지만(오버 페칭), 여러 리소스에 걸쳐 있는 데이터가 필요한 경우 초기 요청에서 데이터를 제대로 검색하지 못해 여러 번 API 호출을 수행해야 하는 경우가 많습니다(언더 페칭).
반면 GraphQL은 데이터에 대한 완전하고 이해하기 쉬운 설명을 제공하는 단일 엔드포인트를 사용합니다. GraphQL 쿼리는 리소스 속성에 액세스하고 리소스 간의 참조를 추적할 수 있으므로 클라이언트는 한 번의 요청으로 GraphQL 서버에 필요한 모든 데이터를 가져올 수 있으며 오버 페칭 및 언더 페칭 문제를 방지할 수 있습니다.
REST 아키텍처에서는 데이터 구조를 변경할 때 최종 사용자의 시스템 오류와 서비스 중단을 방지하기 위해 팀에서 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 등1 수많은 기업에서 GraphQL API를 도입하여 더 많은 고객이 데이터 사양을 간소화하고, 과도하거나 부적절한 네트워크 데이터 전송을 줄이며, 전반적인 데이터 가져오기 기능을 개선할 수 있게 되었습니다.
뿐만 아니라, 기업과 개발자들은 GraphQL 아키텍처의 오픈 페더레이션을 추진하고 있습니다. 현재 진행 중인 GraphQL 페더레이션은 별도의 GraphQL 서비스를 단일 GraphQL API로 통합하여 모든 기본 백엔드 데이터의 진입점 역할을 하고 단일 요청 데이터 가져오기를 용이하게 하고 있습니다. 그러나 아쉽게도 현재 페더레이션 구현 기능은 특정 공급업체에서만 독점 제공되고 있습니다.
이에 대한 대응 방안으로 IBM은 GraphQL 전용 집계 대신 GraphQL API와 비 GraphQL API 모두에서 데이터 집계를 용이하게 하는 민주화된 페더레이션을 지지하고 있습니다.2
IBM API Connect는 직관적인 경험을 통해 API를 일관되게 생성, 관리, 보호, 소셜화, 수익화하고 온프레미스 및 클라우드 전반에서 디지털 혁신을 지원하는 전체 라이프사이클 API Management 솔루션입니다.
IBM API Connect를 사용하면 프로덕션 수준의 GraphQL API를 몇 분 만에 쉽게 구축하고 배포할 수 있습니다. 데이터 소스의 연결 세부 정보를 제공하기만 하면 안전하고 최적화된 GraphQL API가 즉시 생성됩니다.
API 구축을 위해 이러한 프레임워크가 취하는 두 가지 접근 방식에 대해 알아보고 각 방식의 장단점을 살펴보세요.
2023년 Gartner Magic Quadrant의 API Management 부문 보고서를 읽고 IBM이 지속적으로 API Management 분야의 리더로 인정받는 이유를 알아보세요.
IBM API Connect 툴킷 살펴보기
포괄적인 API Management 솔루션으로 API 가치를 극대화하고 디지털 비즈니스를 강화하세요.
IBM은 2023년 Gartner 보고서: API Management의 핵심 기능 부문에서 리더로 선정되었습니다.
이 튜토리얼은 개발자가 프로젝트에서 기술을 사용하는 방법을 배우는 데 도움이 되는 실습 지침을 제공합니다.
각주
1'IBM, API 관리 분야에서 한 단계 더 도약하기 위해 GraphQL 스타트업 StepZen 인수'(ibm.com 외부 링크), TechCrunch, 2023년 2월 8일
2'GraphQL에 오픈 페더레이션 접근 방식이 필요한 이유' (ibm.com 외부 링크), The New Stack, 2023년 11월 16일