GraphQL 대 REST: 알아야 할 모든 것

게시 됨: 2022-09-20

다음 프로젝트의 기술 스택에 포함될 기술을 선택하는 것은 어려울 수 있습니다. 많은 경우, 특히 GraphQL과 RESTful API 중 하나를 선택할 때 가장 중요한 것은 차기 최고의 API 설계 아키텍처를 선택하는 것입니다.

API를 빌드하는 데에는 SOAP, GRPC, REST 및 GraphQL의 네 가지 중요한 방법이 있습니다. 우리는 API를 구축할 때마다 REST와 GraphQL로 마음을 좁히는 경우가 많습니다. REST가 SOAP 및 GRPC를 사용하여 API를 빌드하는 기존 방식을 변경했기 때문입니다.

GraphQL은 API를 빌드하는 더 나은 방법을 나타내기 때문에 더 나은 REST로 널리 태그가 지정됩니다. 많은 개발자들은 GraphQL이 REST를 대체할 것이라고 믿습니다. 더 많은 사람들이 GraphQL이 개발자가 REST API를 구축하는 동안 직면하는 몇 가지 일반적인 문제를 해결하는 데 도움이 된다는 것을 이미 발견했습니다.

이 가이드 에서 프로젝트에 가장 적합한 API 디자인 아키텍처와 패턴을 선택하는 방법을 알아보세요.

API를 구축하는 이 두 가지 방법은 완전히 다릅니다. 실제로 이러한 기술은 HTTP 요청을 보내고 결과를 받는 방식으로 작동합니다. 둘 다 장단점이 있으며 이 기사에서는 API를 개발하고 확장하는 방식을 변화시킨 이 두 가지 훌륭한 기술에 대해 광범위하게 논의할 것입니다.

자세한 내용을 살펴보기 전에 먼저 GraphQL 및 RESTful API의 의미를 살펴보겠습니다.

GraphQL이란 무엇입니까?

GraphQL은 API 쿼리 언어이자 기존 데이터로 이러한 쿼리에 응답하기 위한 런타임입니다. 또한 가장 복잡한 쿼리도 처리할 수 있는 강력한 도구가 함께 제공됩니다.

GraphQL의 핵심 기능은 요청된 특정 데이터 만 요청하고 수신하는 기능입니다. 이렇게 하면 앱과 함께 API를 훨씬 더 간단하게 확장할 수 있습니다.

GraphQL의 가장 흥미로운 부분은 하나의 끝점에서 모든 데이터를 제공할 수 있다는 것입니다.

GraphQL API 아키텍처 순서도의 스크린샷.
GraphQL API 아키텍처.

위의 다이어그램은 GraphQL 아키텍처의 일반적인 표현입니다. 클라이언트는 다른 장치에서 요청을 하고 GraphQL은 요청을 처리하고 요청된 데이터만 반환합니다. 이것은 RESTful API에서 오버페칭과 언더페칭 문제를 깔끔하게 해결합니다.

성공적인 쿼리를 보여주는 GraphQL 플레이그라운드의 스크린샷.
GraphQL 플레이그라운드에서 성공적인 쿼리.

위의 샘플에서는 GraphQL 플레이그라운드와 단일 엔드포인트로 데이터를 쿼리하는 방법을 보여줍니다. 상단은 API 엔드포인트, 왼쪽은 대륙 이름을 요청하는 쿼리, 마지막으로 오른쪽은 요청한 쿼리에 대한 응답입니다.

GraphQL은 REST API로 작업하는 동안 모바일 앱 개발자의 경험을 해결하기 위해 Facebook에서 만들었습니다. GraphQL은 2015년에 첫 번째 오픈 소스 버전이 출시된 이후 기술 비즈니스의 대기업들이 기술을 채택함으로써 엄청난 성장을 경험했습니다.

GraphQL을 사용하는 회사

다음은 서버에서 GraphQL을 적극적으로 사용하는 일부 회사 및 응용 프로그램의 목록입니다.

페이스북

Facebook은 GraphQL을 만들었으며 2012년부터 모바일 앱을 구동하기 위해 프로덕션에서 사용하고 있습니다. 수십억 달러 규모의 소셜 네트워크 회사는 2015년에 GraphQL 사양을 오픈 소스화하여 다양한 환경과 모든 규모의 팀이 액세스할 수 있도록 했습니다. .

페이스북 로그인 페이지 스크린샷.
페이스북은 GraphQL을 사용합니다.

깃허브

GitHub는 또한 GitHub GraphQL API를 사용하여 통합 생성, 데이터 검색 및 워크플로 자동화를 위한 GraphQL API를 제공하여 GraphQL 사용을 발표합니다. GitHub GraphQL API는 GitHub REST API보다 더 정확하고 유연한 쿼리를 제공합니다.

GitHub 홈 페이지의 스크린샷입니다.
GitHub는 GraphQL도 활용합니다.

핀터레스트

Pinterest는 GraphQL의 얼리 어답터이기도 합니다. 사진 공유의 거인은 GraphQL의 초기 탐색과 수십억 달러 규모의 회사를 지원하는 GraphQL 기술을 사용하는 방법에 대해 공개적으로 논의했습니다.

Pinterest 홈페이지의 스크린샷입니다.
Pinterest는 사이트에도 GraphQL을 사용합니다.

Intuit, Shopify, Coursera 및 Airbnb와 같은 다른 많은 10억 달러 기업은 GraphQL로 애플리케이션을 구동합니다. 그리고 REST에 대한 이러한 광범위한 선호도는 계속해서 증가하고 있습니다.

RESTful API란?

REST는 "Representational State Transfer"의 약자로 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 스타일입니다. 서버와 클라이언트 간에 리소스를 교환하기 위한 원칙과 제약 조건을 정의합니다.

API에서 이러한 원칙을 따르는 경우 해당 API의 애플리케이션을 "RESTful"이라고 합니다. WordPress REST API가 이에 대한 대표적인 예입니다.

다음은 API가 Restful API라고 하기 위해 충족해야 하는 몇 가지 원칙과 제약 조건입니다.

  • 클라이언트-서버 분리: 클라이언트(프론트엔드)와 서버(백엔드)는 완전히 분리되어 있으며 끝점을 통해서만 통신할 수 있습니다.
  • 균일한 인터페이스: 인터페이스 에 표시되는 데이터는 모든 장치에서 동일합니다.
  • Stateless: 서버는 현재 요청이 처음인지 아닌지를 기억하지 못합니다. 요청할 때마다 처음부터 처리하는 데 필요한 모든 정보를 포함해야 합니다.
  • 캐시 가능성: 캐싱 및 세션 저장이 허용되지만 최종 사용자가 데이터 캐싱을 선택 해제할 수 있도록 구성해야 합니다.
  • 계층화된 시스템 아키텍처: API는 클라이언트와 서버가 직접 통신하는지 아니면 중개자를 통해 통신하는지 알 수 없도록 설계되어야 합니다.

아래 다이어그램은 기본 REST 아키텍처입니다. 요청 및 응답이 일반적으로 처리되는 방식을 보여줍니다.

RESTful API 아키텍처의 분기 차트를 보여주는 스크린샷.
REST API 아키텍처.

GraphQL의 이점

다음은 GraphQL을 사용하여 얻을 수 있는 몇 가지 이점으로, 차세대 10억 달러 앱을 구축하는 데 충분한 이유를 보여줍니다.

단일 API 엔드포인트를 통해 데이터 가져오기

GraphQL의 가장 큰 장점은 단일 API 엔드포인트를 통해 일부 또는 모든 데이터 포인트에 액세스할 수 있다는 것입니다.

RESTful API의 가장 일반적인 문제 중 하나는 정보에 액세스할 수 있는 엔드포인트가 너무 많다는 것입니다. GraphQL에는 단일 엔드포인트만 있으므로 객체에 대한 다양한 정보를 검색하기 위해 여러 요청을 보낼 필요가 없습니다.

아래 다이어그램은 RESTful API 및 GraphQL을 사용하여 리소스를 검색하는 명확한 예를 보여줍니다. GraphQL 서버의 리소스에 액세스하는 엔드포인트는 하나뿐인 반면 RESTful API의 다른 리소스에 액세스하려면 여러 API 엔드포인트가 필요하다는 것을 알 수 있습니다.

RESTful API의 여러 쿼리와 GraphQL에서 처리되는 방법을 보여주는 순서도입니다.
REST 및 GraphQL의 API 엔드포인트.

오버 페치 또는 언더 페치 없음

오버 또는 언더 페칭 문제는 RESTful API의 알려진 문제입니다. 이것은 클라이언트가 고정 데이터 구조를 반환하는 끝점에 도달하여 데이터를 다운로드하거나 예상보다 많거나 적은 검색을 수행할 때입니다.

오버페칭은 요청이 주어진 요청에 필요한 것보다 더 많은 데이터를 수신(또는 "가져오기")하게 만듭니다. 홈페이지에 사용자 이름을 표시할 목적으로 테이블의 모든 사용자를 가져오고 있다고 상상해 보십시오. 이 경우, 오버페칭은 이름을 포함하여(그러나 뿐만 아니라) 각 사용자에 대한 모든 데이터를 반환합니다.

언더페칭은 비교적 드물지만 특정 엔드포인트가 요청된 모든 정보를 제공하지 못할 때 발생합니다. 클라이언트는 필요에 따라 다른 정보에 액세스하기 위해 추가 요청을 해야 합니다.

GraphQL은 추가 세부 정보 없이 클라이언트가 요청한 정확한 리소스를 잡아서 오버 페치 또는 언더 페치 문제를 효율적으로 해결합니다.

복잡한 시스템 및 마이크로서비스의 더 나은 처리

GraphQL은 통합된 다중 시스템의 복잡성을 통합하고 숨길 수 있습니다.

예를 들어 모놀리식 백엔드 애플리케이션에서 마이크로서비스 아키텍처로 마이그레이션하려고 한다고 가정해 보겠습니다. GraphQL API는 다양한 마이크로 서비스를 하나의 GraphQL 스키마로 병합하여 통신을 처리하는 데 도움이 됩니다.

이러한 스키마가 정의되면 프런트엔드는 스키마의 데이터가 시스템 전체에서 항상 동기화된다는 것을 알고 있기 때문에 프런트엔드와 백엔드 모두 추가 변경 없이 별도로 통신할 수 있습니다.

빠르고 안전한

오버페칭 문제로 인해 클라이언트의 대역폭이 더 많이 소모되어 시간이 지나면 애플리케이션에서 지연이 발생할 수 있습니다. RESTful API 디자인 패턴을 사용하면 막대한 페이로드에서 필요한 정보를 분류하는 데 더 많은 시간이 걸립니다.

Over fetching 및 under fetching을 방지하는 GraphQL의 기능으로 인해 서버는 API 요청 및 응답을 더 빠르게 만드는 안전하고 읽기 쉽고 예측 가능한 형태를 반환합니다.

REST의 이점

GraphQL의 인기가 높아지고 있지만 REST는 여전히 가장 인기 있는 API 표준 중 하나입니다. 그 이유를 살펴보겠습니다.

  • 학습 곡선: RESTful API는 배우고 이해하기 가장 쉽습니다. 이것이 다른 API에 대한 주요 이점입니다.
  • 직렬화: REST는 JSON에서 데이터 직렬화를 위한 유연한 접근 방식 및 형식과 함께 제공됩니다.
  • 캐싱: REST API는 HTTP 프록시 서버 및 캐시의 도움으로 높은 로드를 관리할 수 있습니다.
  • 복잡한 요청: REST API에는 여러 요청에 대해 별도의 엔드포인트가 있으며, 이는 다른 API보다 복잡한 요청을 더 쉽게 관리할 수 있도록 도와줍니다.
  • 깨끗하고 단순함: REST API는 우아하고 단순하며 깨끗합니다. 그들은 탐색하기 쉽습니다.
  • 표준 HTTP 절차: REST는 표준 HTTP 절차 호출을 사용하여 데이터를 검색하고 요청합니다.
  • 클라이언트/서버: 이는 비즈니스 로직이 프레젠테이션에서 분리되었음을 의미합니다. 따라서 다른 하나에 영향을 주지 않고 하나를 변경할 수 있습니다.
  • REST는 Stateless임: 클라이언트와 서버 간에 교환되는 모든 메시지에는 메시지로 수행할 작업을 아는 데 필요한 모든 컨텍스트가 있습니다.

GraphQL의 단점

이제 GraphQL과 REST의 장단점에 대해 논의했으므로 GraphQL의 몇 가지 단점을 살펴보겠습니다.

  • 어려운 학습 곡선: GraphQL은 REST만큼 배우기 쉽지 않습니다. GraphQL API를 구축할 때 가장 어려운 부분은 스키마를 설계하는 것입니다. 이것은 많은 시간과 도메인 지식이 필요합니다.
  • 파일 업로드: GraphQL에는 기본 파일 업로드 기능이 없습니다. Base64 인코딩을 사용하여 이 문제를 해결할 수 있지만 이러한 방식으로 인코딩 및 디코딩하는 비용은 시간과 비용이 많이 소요될 수 있습니다.
  • 웹 캐싱: 캐싱은 서버에 대한 빈번한 트래픽을 줄이는 데 도움이 되며, 자주 액세스하는 정보를 서버에 가깝게 유지하여 요청 및 응답 프로세스의 속도를 높입니다. GraphQL은 HTTP 캐싱 방법을 지원하거나 의존하지 않으며 대신 Apollo 또는 Relay 클라이언트의 캐싱 메커니즘에 의존합니다.
  • 소규모 애플리케이션에 적합하지 않음 : GraphQL은 소규모 애플리케이션 구축에 가장 적합한 API 아키텍처가 아닐 수 있습니다. 앱에 GraphQL이 제공하는 보다 유연한 쿼리가 필요하지 않은 경우 REST를 사용하는 것이 좋습니다.
  • 복잡한 쿼리 문제: 클라이언트가 원하는 것을 정확히 제공하는 GraphQL의 기능은 쿼리 전파 문제로 이어질 수도 있습니다. 클라이언트가 중첩된 쿼리를 너무 많이 제출하면 잘못된 쿼리가 전송되어 서버에 매우 많은 시간이 소요될 수 있습니다. 이러한 요청을 충족하려면 사용자 지정 끝점과 함께 REST를 활용하는 것이 좋습니다.

REST의 단점

이제 REST의 몇 가지 단점에 대해 알아보겠습니다.

다운타임 및 WordPress 문제로 어려움을 겪고 계십니까? Kinsta는 시간을 절약하도록 설계된 호스팅 솔루션입니다! 우리의 기능을 확인
  • 다중 왕복: REST API의 가장 큰 문제는 수많은 엔드포인트의 특성입니다. 이는 클라이언트가 완전한 애플리케이션을 위한 모든 리소스를 가져오려면 데이터를 가져오기 위해 수많은 왕복을 수행해야 함을 의미합니다.
  • 오버페칭과 언더페칭: 오버페칭과 언더페칭 의 문제는 RESTful API의 주요 단점입니다. 원하지 않는 큰 페이로드를 가져오기 때문에 응답이 지연될 수 있습니다.
  • 계층 구조: REST API는 리소스를 참조하는 URI를 기반으로 하기 때문에 자연스럽게 구성되거나 단순한 계층 구조로 액세스되지 않는 리소스에는 적합하지 않습니다.

REST 대신 GraphQL을 사용하는 이유

다음으로 RESTful API 대신 향후 API 개발에 GraphQL을 고려해야 하는 이유에 대해 설명합니다.

강력한 형식의 스키마

GraphQL은 강력한 유형 시스템을 사용하여 API의 기능을 정의합니다. GraphQL에서 SDL(스키마 정의 언어)은 클라이언트가 서버의 데이터에 액세스하는 방법을 둘러싼 매개변수를 정의하는 데 사용됩니다. 클라이언트에 노출되는 모든 API는 SDL에 기록되어 RESTful API에서 볼 수 있는 데이터 불일치 문제를 해결합니다.

오버 페칭 또는 언더 페칭 없음

오버 또는 언더 페치 문제는 클라이언트가 요청한 것보다 많거나 적은 정보를 반환하는 RESTful API의 알려진 문제입니다. GraphQL은 클라이언트가 필요한 정보를 지정할 수 있는 매체를 제공한 다음 해당 특정 정보 만 정확하게 반환함으로써 이 문제를 해결합니다.

다중 엔드포인트

RESTful API의 가장 큰 문제 중 하나는 정보에 액세스할 수 있는 엔드포인트가 너무 많다는 것입니다.

특정 사용자의 ID 번호를 통해 액세스하려고 한다고 가정해 보겠습니다. /users/1 과 같은 엔드포인트가 표시됩니다. 그러나 해당 사용자의 사진에 액세스하려면 /users/1/photos 와 같은 다른 엔드포인트로 요청을 보내야 합니다.

GraphQL에는 단일 엔드포인트가 있으며 사용자에 대한 다양한 정보를 검색하기 위해 여러 요청을 보낼 필요가 없습니다.

GraphQL 대 REST 대결

마지막으로 GraphQL과 RESTful API의 주요 차이점을 살펴보겠습니다. 그런 다음 좋은 API 디자인의 몇 가지 기능에 대해 논의하고 각 기술이 이를 처리하는 방법을 비교할 것입니다.

성능

GraphQL은 모든 리소스에 액세스할 수 있는 단일 엔드포인트를 제공할 수 있기 때문에 RESTful API보다 성능이 더 빠릅니다. RESTful API는 여러 엔드포인트를 사용하므로 네트워크 지연이 발생할 수 있습니다.

쿼리 복잡성

끝점은 여러 끝점으로 분리되지 않기 때문에 GraphQL 쿼리는 시간이 지남에 따라 점점 더 복잡해질 수 있습니다. 반면 RESTful API 엔드포인트는 분리되어 RESTful API를 단순 쿼리로 제한합니다.

인기 및 커뮤니티 지원

GraphQL은 성장하는 API 아키텍처 패턴 및 쿼리 언어입니다. 아직 어리지만 채택률과 리소스 풀이 빠르게 증가하고 있으며 스스로 배우고자 하는 사람들을 위한 리소스가 이미 풍부합니다.

반면 REST는 이미 광범위한 커뮤니티 지원을 자랑하며 소규모 마이크로서비스를 구축하는 기업부터 복잡한 소셜 앱을 만드는 기업에 이르기까지 모든 종류의 기업에서 계속 사용하고 있습니다.

현재 GraphQL 대 REST의 인기 경쟁은 무승부입니다. 두 기술 모두 계속해서 널리 사용되고 있으며 개발 커뮤니티에서 잘 지원하고 있습니다.

학습 곡선

GraphQL의 학습 곡선은 가파르다. API 개발 및 일반 소프트웨어 엔지니어링에 대한 좋은 도메인 지식이 필요합니다. 완전한 초보자는 복잡한 응용 프로그램을 구축할 만큼 충분히 GraphQL을 이해하는 데 어려움을 겪을 것입니다.

반대로 REST는 시작하기가 매우 쉽고 필요한 도메인 지식이 덜 필요합니다. RESTful API는 대부분의 주요 프로그래밍 언어 및 인기 있는 프레임워크에 잘 통합되어 있어 매우 쉽게 배울 수 있습니다.

GraphQL과 RESTful API 비교를 보여주는 스크린샷.
GraphQL 대 REST.

요약

GraphQL은 REST가 SOAP API 패턴의 문제를 해결하기 위해 도입된 것처럼 RESTful API 아키텍처 패턴의 트랙을 따르는 새로운 기술입니다.

GraphQL은 더 빠른 응답, 모든 쿼리에 대한 단일 API 엔드포인트, 일관된 데이터 액세스를 위한 엄격한 스키마를 제공합니다. 이러한 이유 때문에 수십억 달러 규모의 기업이 초기 단계에서도 GraphQL로 전환하기 시작했습니다. 그러나 한계에도 불구하고 GraphQL의 조상 REST는 계속해서 무대에서 강력한 존재감을 유지하고 있습니다.

GraphQL 또는 RESTful API? 이 가이드에서 자세히 알아보기 트윗하려면 클릭

이 가이드에서는 선호하는 기술을 자신 있게 결정할 수 있도록 각 기술의 장점과 단점을 포함하여 GraphQL 및 RESTful API에 대해 알아야 할 모든 것을 살펴보았습니다. 또한 오버페칭, 언더페칭 및 다중 엔드포인트와 같은 RESTful API의 알려진 문제와 GraphQL이 이러한 문제를 해결하고 앱 성능을 향상시키는 방법에 대해서도 논의했습니다.

이제 GraphQL과 REST가 다음 프로젝트에 적합한지 여부를 선택할 수 있는 충분한 통찰력을 얻었습니다. 선택한 우승자와 함께 무엇을 만들 것인지 의견 섹션에 알려주십시오!