GraphQL vs REST: 차이점, 유사점, 사용 이유

GraphQL과 REST의 차이점과 유사점, 그리고 사용 이유와 방법에 대해 배울 것입니다.

현대의 응용 프로그램은 우리가 전에 없이 세상과 연결될 수 있게 해줍니다. 그러나 이 구조가 서로 다른 애플리케이션 간의 강력한 연결과 서로 다른 장치 간의 데이터 공유를 제공하는 데 어떻게 효과적입니까? 개발자는 API(Application Programming Interface)를 사용하여 복잡한 기능을 구축하고 애플리케이션 기능을 리소스로 노출할 수 있습니다.

API의 목적은 클라이언트와 서버 간의 통신입니다. 여기에는 데이터 전송, 데이터 보안 및 다양한 네트워크 및 타사 애플리케이션으로의 배포 프로세스가 포함됩니다. API의 장점은 사용자 지정 코드나 통합을 제공하지 않고는 얻을 수 없는 정보와 기능에 누구나 액세스할 수 있다는 것입니다.

개발자로서 API 서비스를 만들고 리소스를 사용하는 데 사용할 수 있는 다양한 프로토콜과 아키텍처가 있습니다. 여기에는 다음이 포함됩니다:

• REST
• RPC
• GraphQL
• SOAP

GraphQL이 REST와 어떻게 비교되는지 알아보겠습니다.

 

 

GraphQL란

GraphQL은 클라이언트와 서버 간의 데이터 통신에 사용되는 API에 대한 쿼리 언어입니다. GraphQL은 일반적으로 스키마를 사용하여 서버의 데이터를 쿼리하거나 원격으로 데이터를 변환하도록 정의됩니다. GraphQL은 서버에 강력한 유형의 도구를 제공합니다. GraphQL로 작업할 때 프런트엔드 개발자는 항상 서버에서 반환되는 데이터의 정확한 모양을 알 수 있습니다. 이를 통해 REST 및 SOAP 접근 방식보다 훨씬 유연하고 효율적으로 데이터 기반 애플리케이션을 구성할 수 있습니다.

GraphQL을 사용하면 API의 데이터가 완전하고 명확하게 설명됩니다. 클라이언트는 필요한 것만 요청할 수 있습니다. 결과적으로, API를 시간에 따라 확장하는 것이 더 간단하고 강력한 개발자 도구가 가능합니다. 또한 애플리케이션 개발자는 애플리케이션에서 데이터가 사용되는 방식에 대해 더 나은 유연성을 제공합니다.

 

 

REST란

REST는 Representative State transfer의 약자입니다. HTTP를 통한 통신 방식을 정의합니다. REST 아키텍처는 고유한 URI(Uniform Resource Identifier)(엔드포인트)로 리소스를 노출합니다. 클라이언트는 이 끝점을 사용하여 요청을 전송하여 서버에 액세스합니다. 각 엔드포인트는 GET, POST, PUT, DELETE 및 PATCH와 같은 HTTP 메서드를 기반으로 실행됩니다. 이러한 방식으로 서버에 대한 각 리소스는 단일 HTTP 메서드를 실행하는 단일 엔드포인트를 사용하여 사용됩니다.

이 두 가지가 어떻게 작동하는지 이해하기 위한 기본적인 예를 확인해 보겠습니다.

 

 

GraphQL vs REST: 실용적인 예

REST는 API를 만드는 가장 오래되고 인기 있는 방법 중 하나입니다. 그러나 GraphQL과 REST 아키텍처 사이에는 API를 구현하는 방법과 큰 차이가 있습니다. 이 두 가지 접근 방식 간의 높은 수준의 차이에 대해 알아보겠습니다.

사용자 정보, 해당 사용자의 게시물 및 해당 사용자와 연결된 팔로워를 표시하는 소셜 미디어 응용프로그램의 기본 예를 들어 보겠습니다.

REST 아키텍처를 사용하는 경우 이러한 리소스를 가져오기 위한 요청 유형이 각각 있는 세 개의 서로 다른 URL(엔드포인트)이 필요합니다. 다음은 다음 URL에 대한 프레젠테이션입니다:

GraphQL vs REST: 차이점, 유사점, 사용 이유 1

 

 

GraphQL 접근 방식을 사용하는 경우 클라이언트는 실제로 세 개의 엔드포인트를 사용하여 이러한 데이터를 가져오는 것과 동일한 데이터를 얻기 위해 하나의 엔드포인트만 사용하여 단일 요청을 보내면 됩니다. 다음은 기본적인 예입니다:

GraphQL vs REST: 차이점, 유사점, 사용 이유 2

 

 

GraphQL을 사용할 때 클라이언트는 필요한 데이터만 쿼리합니다. 위의 REST 예제에서 각 요청은 해당 단일 끝점과 관련된 모든 데이터를 가져옵니다. 예를 들어 사용자를 반환하려면 엔드포인트에서 다음과 같이 데이터를 반환합니다:

GraphQL vs REST: 차이점, 유사점, 사용 이유 3

 

 

팔로워의 이름만 얻으려고 한다고 가정해 보겠습니다. GraphQL API는 다음과 같은 시나리오에서 유용합니다:

GraphQL vs REST: 차이점, 유사점, 사용 이유 4

 

 

원하는 정확한 데이터를 기반으로 더 많은 매개 변수를 추가할 수 있습니다:

GraphQL vs REST: 차이점, 유사점, 사용 이유 5

 

 

GraphQL과 REST의 차이점

작동

이제 이 두 가지 접근 방식을 이해했으므로, 두 접근 방식 사이에 존재하는 차이점을 알아보기 위해 깊이 잠수해 보겠습니다.

위에서 도출한 정의에 따라 REST는 CREATE, READ, UPDATE 및 DELETE와 같은 다양한 작업을 수행합니다. 이러한 각 작업은 HTTP 메서드를 사용하여 실행됩니다. 여기에는 GET, POST, PUT 및 DELETE가 포함됩니다. API의 각 리소스는 각 엔드포인트를 사용하여 액세스됩니다. REST API를 사용하려면 각 HTTP 메서드를 해당 작업에 매핑하고 각 API Endpoint에 URI를 제공하는 컨트롤러가 필요합니다.

반대로 GraphQL은 컨트롤러가 HTTP 메서드를 관리할 필요가 없습니다. 운영 측면에서, 그것은 쿼리 돌연변이 구독 접근법을 사용합니다.

이렇게 하면 GraphQL에는 끝점이 하나만 있습니다. 모든 API 호출은 GraphQL 응용 프로그램 내의 모든 작업에 대해 해당 엔드포인트로 전송됩니다. 따라서 HTTP 메서드 매핑을 관리하는 컨트롤러가 필요하지 않습니다. 단일 엔드포인트는 API 작업을 관리하기에 충분합니다.

 

 

API 조직

REST는 엔드포인트를 사용하여 API 리소스에 액세스하는 반면 GraphQL은 스키마 및 유형 시스템을 사용합니다. 다른 필드에 액세스하려면 스키마를 제공해야 합니다. GraphQL에서는 GraphQL 유형 시스템을 따르는 스키마를 사용하여 응답에서 원하는 필드를 전달해야 합니다. 이는 유형 시스템이 자동 오류 확인 및 유효성 검사를 제공하므로 API의 안정성을 높입니다.

 

 

API 응답

REST API에는 고정된 예상 API 응답이 있습니다. 고객에게 20개의 필드를 노출한다고 가정해 보겠습니다. 모든 요청은 응답의 10개 필드를 반환합니다. 마찬가지로, 모든 클라이언트는 해당 특정 API에 대한 응답에서 10개의 필드를 얻습니다. 그러나 GraphQL API는 전송된 요청을 수정하고 클라이언트가 정확한 필드만 받도록 하는 유연성을 제공합니다. 즉, 다양한 소비자가 응답의 다른 필드에 질문하고 특정 고객이 동일한 작업에 대해 원하는 것만 고수할 수 있습니다.

 

 

오버 및 언더 페칭

API 응답에 따라 REST 기반 API는 오버페치 또는 언더페치를 발생시킬 수 있습니다. 그것은 고정된 반응을 가지고 있습니다. 고객이 30개의 필드 목록에 10개의 필드를 입력하려는 경우 REST는 이를 단순화할 수 없습니다. 이렇게 하면 응답에서 추가로 20개 필드를 오버페치할 수 있으며, 이는 클라이언트에 필요하지 않습니다. 다른 시나리오에서는 사용자가 사용자 ID를 기반으로 이름과 성을 가져오기 위해 GET 요청을 보내는 경우. 이로 인해 API가 클라이언트에 이름만 노출하는 경우 언더페치가 발생할 수 있습니다. GraphQL의 응답 유연성 덕분에 API 오버 및 언더 페치를 제거합니다.

 

 

GraphQL 또는 REST를 사용해야 하는 경우

API를 만드는 이 두 가지 방법은 강점에 따라 사용하는 것이 가장 좋습니다. 각 접근 방식에 가장 적합한 몇 가지 사용 사례에 대해 살펴보겠습니다.

 

그래프QL

• 그래프QL은 내포된 데이터와 함께 사용할 때 가장 적합합니다. 예를 들어, 위에서 설명한 실제 예제를 사용하면 GraphQL은 모든 게시물과 관련된 주석을 가져올 때 가장 잘 작동합니다. 따라서 뉴욕 시간대와 같은 기업의 데이터 소스와 함께 사용하는 것이 가장 좋습니다.
• GraphQL은 오버페칭을 제어하는 기능으로 모바일 기기나 스마트워치를 사용할 때처럼 대역폭이 제한적일 때 유용합니다.
• GraphQL은 마이크로 서비스를 처리하는 데 사용될 때 가장 빛납니다. GraphQL은 마이크로서비스 아키텍처가 필요한 다른 소스에서 데이터를 소비하고 가져올 때 잘 작동합니다.
• GraphQL은 응답의 유연성 때문에 클라이언트가 API를 사용할 시기를 예측할 수 없는 데이터로 작업할 때 좋은 선택입니다. 이는 API를 공개하고 싶을 때 사용됩니다. 클라이언트는 API를 사용하여 사용자가 예측할 수 있는 다양한 리소스를 가져올 수 있습니다.

 

REST 접근법

• 하나의 클라이언트만 서비스하기 위한 간단한 API를 만들 때 대역폭 성능이나 데이터를 가져오기 위한 여러 라운드에 대해 걱정할 필요가 없는 경우 REST를 선택하는 것이 좋습니다.
• REST는 클라이언트와 작업을 미리 결정하는 HTTP 메서드가 다르기 때문에 이 메서드를 사용하여 지정된 클라이언트가 수행할 수 있는 작업을 기반으로 특정 클라이언트가 액세스할 수 있는 엔드포인트를 제어할 수 있습니다.
• 잘 설계된 API 사용 사례가 필요하다면 REST가 좋은 선택입니다. 다른 HTTP 방법에 따라 데이터를 제한할 수 있습니다.
• REST는 HTTP 메서드를 사용하여 클라이언트에 대해 구현을 예측할 수 있습니다. REST는 특정 데이터 구조가 있을 때 가장 빛납니다.
• 요청을 캐시하려는 경우 REST가 잘 작동합니다. REST는 캐슁을 원활하게 하는 다양한 엔드포인트를 사용합니다. GraphQL은 단일 엔드포인트와 사용자 지정 요청을 사용하므로 캐싱 기술을 즉시 구현하기 어려울 수 있습니다.
• GraphQL은 JSON 형식을 사용하여 노출된 데이터만 표시합니다. XML 및 HTML과 같은 다른 방법을 사용하여 데이터를 노출해야 하는 경우 REST가 바로 이에 적합합니다.

 

위의 사용 사례를 기준으로 GraphQL 또는 REST가 특정 상황에서 작동하지 않는다는 것을 의미하지 않습니다. 이것은 각 접근 방식이 가장 빛날 때만 설명합니다.

 

 

Memphis.dev란?

멤피스는 차세대 메시지 브로커입니다.

단순하고 강력하며 내구성이 뛰어난 클라우드 네이티브 메시지 브로커를 통해 차세대 이벤트 중심 사용 사례를 빠르고 안정적으로 개발할 수 있습니다.

Memphis는 운영을 전혀 필요로 하지 않으며, 신속한 개발을 지원하고, 비용을 대폭 절감하며, 코딩 장벽을 제거하고, 데이터 지향 개발자와 데이터 엔지니어의 개발 시간을 크게 절약합니다.

 

멤피스의 네 기둥

• 안정성: 큐와 브로커는 현대 애플리케이션 구조에서 중요한 역할을 하므로 가용성이 높고 안정적이어야 합니다.
• 성능 및 효율성: 효율적인 리소스 소비를 유지하면서 우수한 성능을 제공합니다.
• 관찰 가능성: 문제 해결 시간을 0에 가깝게 단축합니다.
• 개발자 경험: 신속한 개발, 모듈화, 인라인 프로세싱 및 스키마 관리.

 

Memphis는 다양한 사용 사례와 사용 편의성을 위해 REST를 통한 메시지 생성을 가능하게 하기 위해 HTTP를 통해 메시지를 수신하는 REST 게이트웨이를 추가했습니다.

인기 있는 사용 사례는 브라우저, 사용자 세션, 프런트엔드에서 직접 이벤트를 생성하고 타사 앱을 통해 데이터를 수신합니다.

 

 

Mempis.dev의 GraphQL

데이터 파이프라인은 지속적으로 데이터 품질 문제, 가용성 문제를 발생시키고 있으며 서비스 구현자, 데이터 엔지니어 및 데이터 소비자 간의 통신 격차가 발생하고 있습니다.

잘 구성된 스키마를 정의하고 다양한 데이터 생산자에게 적용함으로써 데이터의 품질을 높이고, 비정형 데이터 변환에 필요한 클라이언트 로직을 낮추고, 파이프라인 및 소비자 중단을 줄입니다.

Mempis Schemaverse는 독립 실행형 컴퓨팅 또는 전용 리소스 없이 멤피스 브로커 위에 강력한 스키마 저장소 및 스키마 관리 계층을 제공하기 위해 만들어졌습니다. 기술 및 비기술 사용자는 고유하고 현대적인 UI 및 프로그래밍 방식을 사용하여 서로 다른 스키마를 생성 및 정의하고 스키마를 여러 스테이션에 첨부하고 스키마를 적용할지 여부를 선택할 수 있습니다. 멤피스의 저코드 접근 방식은 생산자 라이브러리에 내장된 직렬화 부품을 제거합니다. 스키마 X는 버전 관리, GitOps 방법론 및 스키마 진화를 지원합니다. Schemaverse는 Protobf, JSON 및 GraphQL을 지원합니다.

 

 

결론

GraphQL은 그래프를 사용하여 데이터를 쿼리할 개체를 나타냅니다. REST와 달리 GraphQL은 단일 끝점을 사용하여 서버에서 서로 다른 리소스에 액세스합니다. 그래프와 같은 표현을 사용하면 특정 지점에서만 클라이언트가 원하는 데이터를 쿼리할 수 있습니다.

이 예제를 통해 기존 REST와 GraphQL 접근 방식의 주요 차이점을 더 잘 이해할 수 있기를 바랍니다.