본문 바로가기

카테고리 없음

GraphQL 은 분산형 웹(DWeb)의 도입을 앞당길 것입니다.

블록체인 및 스토리지 네트워크를 데이터 상호 운용성 계층으로써 활용하는 것에 대해 

(원문: https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a)

 

오늘날까지도 SQL 여전히 수십 년째 대부분의 조직, 소프트웨어 애플리케이션 및 기관에서 데이터베이스로 활용됩니다. 하지만 블록체인의 출현으로 우리는 마침내 관계형 데이터베이스에 대한 대안을 찾았고, 이는 NoSQL등이 점진적으로 가져온 발전에 대해서만 이야기하는 것이 아닙니다. 현재 분산 (Decentralized Web) 또는 Web3로 불리며, 독점 API가 아닌 데이터가 상호운용성(interoperability) 기반이 되는 새로운 패러다임의 시작에 있습니다. 이 에서는 이러한 변화가 발생하는 이유와 GraphQL 쿼리 언어가 새로운 데이터 상호 운용성 시대에 힘을 실어 줄 수 있는 특징에 대해 설명합니다 . 

 

독점 (proprietary) API의 문제점 

오늘날의 웹은 중앙 집중화 된 SQL 데이터베이스의 한계를 극복하기 위해 주로 독점 API를 통해 연결되어 있습니다.이러한 상황에 대해서 이더리움 재단에서 근무했던 Vinay Gupta는 다음과 같이 설명하고 있습니다: 

 

조직의 중심에 모든 진실과 지혜를 저장하는 하나의 큰 데이터베이스가 있으면 다른 사람들이 해당 데이터베이스를 만지는 것에 매우 조심스럽게 됩니다. 

 

따라서 서버에서 실행되는 독점 API 는 들어오는 내용, 나가는 사람, 형식을 제한하며 중앙 데이터베이스에 대한 보호 장벽 역할 을 합니다. 더 나아가 마이크로 서비스 패턴을 사용하면 조직 내에서 데이터를 캡슐화하여 서로 다른 팀에 의해 구축된 API는 서로 다른 API를 거치게 됩니다. 이로 인해 현재 데이터베이스에는 상당한 발전이 있었지만, 이러한 API 확산에는 다음과 같은 단점이 있습니다. 

 

1. API는 유연하게 활용되지 못하며 유지 관리 비용이 많이 듭니다

 

2. API가 사용되는 현재 모델은 비효율적입니다.

 

3. 사유 API는 데이터 독점으 이어집니다. 

 

 항목을 더 자세히 살펴보도록 하겠습니다. 

 

1. API는 유연하게 활용되지 못하며 유지 관리 비용이 많이 듭니다 

API, 특히 REST API는 웹 어플리케이션과 같은 특정 사용 사례를 염두에 두고 설계되었으며 이러한 예시가 아닐 경우 활용성이 떨어집니다. 

이로 인해 조직 내에서는 API로 커버해야 하는 영역이 끝없이 확장됩니다. 새로운 각 기능에는 새로운 엔드 포인트로 API를 확장하기 위한 추가 엔지니어링 작업이 필요하게 되며 새로운 엔드 포인트마다 해당 기간 동안 유지 및 지원하기위한 지속적인 엔지니어링 작업이 필요합니다. 그리고 이 모든 작업은매우 오래 걸릴 수 있습니다.   

 

한편 공용 API 소비자의 경우 API 개발자가 지원하기로 결정한 범위에서만 사용을 할 수 있는 한계에 맞닥뜨리게 됩니다. Github의 에코 시스템 엔지니어링 이사 인 Kyle Daigle 은 다음과 같이 문제를 진단하고 있습니다: 

 

거의 모든 API가 디자인에 따라 연동하게 됩니다. 제가 생각할 수 있는 모든 API는 모두 사용자가 사용하기를 원하는 방식에 대한 아이디어를 가지고 있으며, 이를 바꾸는 것은 기본적으로 불가능합니다 … 엄청난 양의 데이터베이스를 긁어 내고, 데이터베이스에 저장하고, 본질적으로 이를 중심으로 자체 API를 구축하지 않는 이상 말이죠. 

 

이러한 공개 API의 경직성을 해결하기 위해 추가적으로 많은 엔지니어링 노력이 필요하며, 이는 다음 문제점과 연결됩니다. 

 

2. 현재 모델은 비효율적입니다. 

앞서 살펴본 바와 같이 API의 경직성은 더 많은 데이터베이스 및 API의 확산으로 이어지며, 종종 정확히 동일한 데이터  단순히 다른 형식으로 또는 다른 API 이름으로 저장하는 경우가 빈번합니다. 또한 이러한 각각의 새로운 데이터베이스 및 API에는 추가 인프라와 API, 그리고 유지 관리할 엔지니어링 리소스가 필요하게 됩니다.  

 

이러한 현상은 엄청난 양의 비효율로 이어지게 되는데, 다시 Vinay Gupta의 발언을 이용하자면 다음과 같이 묘사할 수 있습니다: 

 

당신이IRS에 양식을 제출하면 6 ~ 7 개의 프로세스를 거쳐 데이터베이스에 저장됩니다  전체 과정 여러 개의 프로세를 거쳐야 하고 중앙집중적이며 어렵습니다. 

 

Brendan O’Brie Michael Hucka의 연구논문에서, 현재의 이 패턴 "중간 데이터베이스" 패턴이라고 묘사하며 SQL 데이터베이스의 우위를 아래와 같이 설명하고 있습니다:   

https://qri.io/papers/deterministic_querying/  에서 설명하는 "중간 데이터베이스 "  패턴 

 충분히 발전된 형태의 소프트웨어 시스템은 하나의 데이터베이스에서 데이터를 인코딩하고, 네트워크를 통해 제공하고, 데이터를 디코딩하고, 다른 데이터베이스에 저장하 프로세스를 여러 번 반복하는 수많은 서버를 포함합니다. 

 

O'Brien과 Hucka는 이러한 데이터 파이프 라인에서 중간 단계의 결과가 개인 데이터베이스에 저장되거나 이 데이터를 공개적으로 사용할 수 있도록 구축하는데 필요한 엔지니어링 노력으로 인해 결과물이 완전히 버려지는  얼마나 흔한지 설명합니다. 결과적으로 이는 데이터 파이프 라인 내에서 그리고 각 팀과 조직의 데이터 파이프라인을 거치며 동일한 결과물을 중복해서 만들게 됩니다.

 

3. 독점 API는 데이터의 독점으 이어집니다. 

데이터를 사일로에 두면 도덕적 해이를 가져오기도 합니다. 이는 기술 분야에서 일반적으로 논의되는 내용이며, 주요 대기업들이 이전에 자신들의 플랫폼에서 개발을 하도록 장려하다가 이후에 독점 API에 대한 접근 권한을 취소하는 경우가 발생하곤 하는 사례가 기술 분야에서 흔합니다. 

 

페이스북은 경쟁을 막기 위해 의도적으로 위와 같은 형태의 행동을 취했으며 트위터 역시도 효과적으로 데이터를 통한 수익을 창출하기 위해 동일한 행동을 하기도 했습니다.인포 월드(InfoWorld)의  수석 작가, Serdar Yegulalp는 트위터의 사례를 다루며 독점 API 구축의 위험성을 간결하게 설명하고 있습니다:     

이를 API 시스템 본질적인 리스크 중 하나라고  수 있을 것 같습니다: 데이터 소스, 분석 레이어 또는 인프라 등 단일 엔티티에 대한 의존도가 더 광범위하고 다면적 일수록 이에 대한 지원을 중단하기 더 쉬워지게 됩니다. 

데이터가 게이트 키퍼를 통해 보호받을 수 밖에 없는 소프트웨어 아키텍처 패러다임은 이러한 데이터 사유의 악성적인 관행을 자연스럽게 초래합니다. 

 

위와 같은 문제점에도 불구하고도, API  기반으로 하는 현재의 시스템은 엄청난 성공을 거두었습니다. API는 개발자가 Stripe 또는 Twilio 같은 특수한 목적의 구성요소를 가지고 소프트웨어 개발할 수 있는 기반을 마련하여 헤아릴  없는 경제적 가치를 창출했습니다. SQL이 지배하는 현재의 기술 환경에서 애플리케이션간에 데이터를 안전하게 전송할 수 있게 되면서 오늘날 우리가 알고 사랑하는 인터넷은 API 없이는 불가능했을 것입니다. 하지만 이제는 블록체인과 다른 Web3 기술의 출현으로 인터넷에서 자연스러운 상호 운용성의 시대가 열리게 되었습니다. 

 

블록체인 및 주소 기반의 컨텐츠 스토리지 시스템의 탄생 

대부분의 NoSQL 데이터베이스와 마찬가지로 SQL의 핵심적인 단점은 데이터가 하나의 데이터베이스에서 모두 변경된다 입니다. Clojure 프로그래밍 언어와 Datomic 데이터베이스를 만든 Rich Hickey 이를 PLOP (place-oriented programming, 공간 지향 프로그래밍)이라고 부르고 있습니다. 과거 작은 메모리와 디스크 크기의 한계를 극복하기 위해 이러한 모델은 필요성이 높았지만, 더 이상 현대 정보 처리 프로세스에서는 그 중요성이 줄어들고 있습니다. 데이터를 임의의 방식으로 하나의 공간에서 변경할  있는 경우 데이터가  마지막으로 액세스 한 이후로 변경되지 않았다거나 여전히 정확하다고 신뢰할 수 없습니다. 따라서 탈 중앙화 을 구현하는 두가지 기술, 블록체인 및 주소 기반의 스토리지의 구현 모두 정보 데이터베이스의 불변성  강조한다는 것은 놀라운 일이 아닙니다. 

 

내용 주소화 스토리지 (content-addressed storage, CAS)

블록체인이 세간의 관심을 훨씬 더 많이 받고 있지만 그 기반에 깔린 내용 주소화 스토리지에 대해 먼저 이해할 필요가 있습니다. 기본적인 개념은 다음과 같습니다. 데이터베이스의 엔티티, 파일 시스템의 파일, CDN의 blob등의 데이터를 어떻게 참조하고 있으신가요? 매번 데이터를 호출할 때마다 임의의 ID, URL 또는 이름을 지정하여 사용하고 계신가요?혹은 로컬 파일 시스템, 원격 서버 또는 제공되는 위치와 관계없이 항상 특정 값으로 확인되는 고유 ID를 부여하여 사용하고 계신가요? 

 

IPFS (Interplanetary File System) 또는 분산 버전 제어 시스템 Git과 같은 내용 주소화 스토리지 네트워크는 해시 함수를 사용하여 유하게 계산된 ID를 사용하여 후자의 참조 방식을 사용합니다. 컨텐츠 ID는 항상 동일한 컨텐츠를 반환하므로 ID를 역으로 계산하는데 사용 데이터 무결성 담보할 수 있습니다.  

 

에서 내용이 주소화된 스토리지 방식은 변경이 불가하다는 특성을 알게 되었는데, 렇다 이를 어떻게 유용하게 사용할 수 있을까요? 세상에 존재하는 모든 데이터는 - 은행 계좌 잔고, 친구 목록, 할 일 목록까지 — 시간이 지남에 따라 변화합니다. 그렇다면 시간이 지남에 따라 변경되는 개념들을 어떻게 변경 불가능한 데이터를 사용하여 표현할 수 있을까요? 이 지점 바로 블록체인이 들어오는 곳입니다. 

 

블록체인 

블록체인의 핵심은 불변하는  추가만 할 수 있는 데이터 구조(블록)에 있습니다. 각 블록은 불변하고 변경되지 않지만 계정 잔액 또는 스마트 계약 상태와 같은 변수를 사용하여 기존 데이터베이스에서 나타나는 수정 방식을 모방할 수 있습니다. 이 패턴에서 우리는 자연스럽게 데이터를 감시할 수 있게 되는데, 시간이 지남에 따라 변수가 어떻게 변했는지 볼 수 있으므로 외부 프로세스가  데이터를 신뢰하여 이용 수 있습니다. 

 

Ethereum과  스마트 컨트랙트 기능이 있는 블록체인은 데이터 조각이 어떻게 수정될 수 있는지, 그리고 누구에 의해 안전한 방식으로 수정될 수 있는지를 체계화합니다. 이는 일반적으로 중앙 집중식 API 제공하는 이점이었습니다. 

 

이러한 혁신은 블록체인에 저장된 데이터와 주소 기반의 컨텐츠 스토리지 네트워크가 상호 운용성 계층으로 작동할 수 있는 새로운 패러다임을 제시하였습니다. 

상호 운용성 계층으로 작동하는 분산화 된 데이터 구조

블록 체인은 탈중앙화 되고 허가 없이 적대적인 환경에서 작동하도록 설계되었기 때문에 안전성과 견고함을 위해 추가적인 보호 계층을 설계할 필요가 없습니다. 블록체인 또는 내용 주소화 스토리지 네트워크에 있는 데이터의 경우 사유 API  이상 필요하지 않게 되며, 프로세스는 상호 운용성을 위해 공유된 분산 데이터와 직접 상호 작용할 수 있습니다. 

 

산화 데이터 호출하는 방법 

블록체인이 새로운 유형의 데이터베이스라면, 이 데이터를 어떻게 호출해야할까요? RESTful API, RPC 호출, SQL 인터페이스를 사용해야 할까요? 답은 위의 모든 것을 사용할 수 있다이지만, 분산형 애플리케이션(dApp)의 경우에는GraphQL 자연스러운 선택이 될 것입니다. 

 

GraphQL 은 REST 또는 RPC API보다 효율적입니다. 

GraphQL 은 Facebook에서 개발하고 오픈 소스로 제공된 쿼리 언어이자 IDL(인터페이스 정의 언어)로써 기존 RESTful API의 경직성과 비효율성을 극복하기 위해 개발되었습니다. 결과적으로 GraphQL은 강력하면서도 사람이 쉽게 이해할 수 있는 쿼리 언어를 API 사용자들에게 제공합니다. 

 

기존 REST ( Representational State Transfer ) API를 사용하면  엔티티 또는 리소스에 해당 엔티티에 대해 수신  데이터를 정의하는 별도의 엔드포인트가 있습니다. 예를 들어 사용자가 속한 조직의 이름을 가져 오려면 먼저 다음과 같은 호출을 보내야합니다: 

/ api / v2 / users / 1 

 

그리고 이후에 다음과 같은 호출을 다시 보내야하죠: 

/ api / v2 / organization / 7 

 

기존 API를 기반으로 구축된 실제 애플리케이션은 수십 또는 수백 번의 왕복 네트워크 호출을 수행해야 할 수 있습니다. 이는 비단 REST 문제만이 닙니다. 인기있는 분산형 애플리케이션인 AdChain 은 Ethereum RPC API를 기반으로 구축되 UI를 로드하기 위해Infura 에 수백 번의 왕복 네트워크 호출을 수행  는데, 이는 네트워크 정체를 초래하고 로드 시간 최적화하기에 어렵습니다.

AdChain 레지스트리가 Infura에 수행한 수백개의 네트워크 호출  기록   https://publisher.adchain.com/domains  

반면에 GraphQL 은 애플리케이션에 필요한 모든 데이터를 하나의 쿼리 로 표현할   강력합니다. 필요한 데이터의 양에 상관없이 GraphQL 사용하면 네트워크 호출을 두 번 이상 수행할 필요가 없습니다. 호출을 했을 때 데이터를 부족하게 얻지 않고 불필요하게 많이 가져오지 않으므로 요청한 데이터만 정확하게 얻을 수 있습니다.     

 

그 결과 인터페이스는 특이한 데이터 호출 방식을 강요하지 않고, 원하는 데이터만 제공하며 외부 개발자의 새로운 사용 방식을 지원하기 위해 지속적인 업데이트가 필요하지 않게 됩니다. 

 

분산된 어플리케이션을 구축하는덴 GraphQL SQL보다 낫습니다. 

렇다면 SQL과 같은 다른 쿼리 언어를 사용하여 데이터 블록 체인을 쿼리하는 것은 어떨까요? 

 

분명하게 말씀드리자면, 다른 쿼리 언어를 사용한 호출은 가능할 뿐 아니라 반드시 사용되어야 한다고 생각합니다. SQL은 세계 수백만의 개발자에게 친숙한 환경을 제공하며 확실히  GraphQL 보다는  강력한 성능을 제공하는 쿼리 언어입니다. 특히 데이터 과학자와 데이터 엔지니어들에게 친숙하며, GraphQL 그들에겐 다소 생소할  있습니다 .하지만 SQL은 분산 어플리케이션을 구축하는데 선호되는 언어는 아닐 것이라고 생각됩니다. 

 

GraphQL 이 블록체인 기반 dApp 구축할때 SQL을 이길  있는 몇 가지 이유 가 있습니다. 

 

1. GraphQL 은 "충분히 강력합니다"

 

2. GraphQL 은 프런트 엔드 개발자들이 더 사용하기 쉽습니다.

 

3. GraphQL 은 조직의 경계를 넘어서도 신뢰하며 사용될 수 있도록 설계되었습니다. 

 

1. GraphQL 은 "충분히 강력합니다" 

 

GraphQL의 쿼리 언어는 기본적으로 SQL과 같이 표현하는 방법이 풍부하진 않지만, GraphQL의 엔드 포인트는 대부분의 SQL 조회 인터페이스에서 기대하는 쿼리 기능을 제공하도록 설계되어 있습니. 예를 들어, GraphQL 사양은 기본적으로 데이터를 수집하는 방법을 지원하지 않지만 이 기능을 수행하는 방법을 지정하 OpenCRUD 와 같은 표준이 등장하여 동일한 기능을 수행하도록 지원합니.   

주체(entity) 임시로 조인하는 등의 일부 롱테일 기능은 GraphQL에서 여전히 지원되지 않습니다. 그러나 추정컨데, 프론트 엔드 플리케이션에 필요한 기능의 99.9 %을 구현하는데 있어GraphQL 충분하다고 여겨집니다. 

 

2. GraphQL 은 프런트 엔드 개발자에게 더 사용하기 쉽습니다. 

GraphQL 을 선택하여 약간의 기능성을 포기하더라도, 사람이 이용하기에 훨씬 직관적인 표현방식을 사용할 수 있습니다. 예를 들어 GraphQL 에는 익숙하게 사용할 수 있는 JSON과 유사한 구문이 있습니다. 

 

query {
  user(id:1) {
    name
    organization {
      name    
    }
  }
}

그리고 GraphQL 쿼리의 응답은 요청의 형태를 정확히 반영하는 JSON 객체로 돌아옵니다. 

 

{
  "user": {
    "name": "Vitalik",
    "organization": {
      "name": "Ethereum Foundation"
    }
}

JSON이웹에서 데이터를 전송하는 데 가장 일반적으로 사용되는 데이터 형식 이라는 점을 감안할 때 이 구문은 대부분의 웹 개발자에게 매우 친숙하게 다가옵니다. 

 

한편 동일한 기능을 수행하는 SQL 쿼리는 다음과 같습니다. 

SELECT user.name, organization.name
FROM user JOIN organization ON (user.organization_id=organization.id)
WHERE user.id=1

 

기에 썩 나쁘지는 않지만 GraphQL 쿼리 보다 덜 간단하다는 것을 알 수 있습니다. 그리고 응답 데이터는 사용중인 특정 SQL 데이터베이스에 종속되어 비정규화되고 표 형식으로 전송될 것입니다. 이렇게 HTTP를 통해 전송되는 일반 텍스트 직관적인 JSON 형식으로 표현되는 GraphQL 응답대조됩니다. 

 

또한 GraphQL 생태계에는 React-Apollo 같은 도구 있어GraphQL을 통해 가져온 데이터를  플리케이션의 UI 구성 요소에 직접 통합하는 것이 매우 간단 합니다. 모바일 또는 웹 어플리케이션에서 HTTP를 통해 SQL을 직접 사용하지 않으므로 이러한 도구는 SQL 생태계에 존재하지 않습니다. 

 

3. GraphQL 은 조직의 경계를 넘어서도 신뢰하며 사용될 수 있도록 설계되었습니다 

가장 중요한 것은 SQL 엔드 포인트가 조직의 신뢰 경계를 넘어서 사용되도록 설계되지 않았다는  입니다 . 예를 들어 SQL을 사용하여 읽기 전용 블록체인 데이터를 제공하는 경우 지나치게 복잡한 SQL 쿼리를 사용하여야 하기에 다른 사람들이 사용하기 쉽지 않을 것입니다. 

GraphQL 은 또한 백엔드에서 값비싼 계산을 임의적으로 수행  있을만큼 강력하며, SQL과 달리 처음부터  문제를 해결하기 위해 설계되어동적으로 시간이 많이 걸리는 쿼리를 차단하고 요청 빈도를 제한할  있는도구 지속적으로늘어나고 있습니다.     

 

SQL에서  문제를 해결하는 전통적인 접근 방식은 느린 쿼리를 수동으로 찾아서 다시 작성하거나 혹은 인덱스를 추가하거나 데이터베이스 스키마를 변경하여 "승인된" 값비싼 쿼리의 영향을 줄이는 방식으로 해결했습니다. 따라서 조직에서 SQL이 배포되는 방식의 특성을 살펴보면 엔드 포인트를 직접 쿼리 할  있는 사람들을 엄격하게 제한하는 특성을 볼 수 있습니다.   

 

GraphQL 조직의 신뢰범위를 넘어서도 사용될  있는 특징이 빛을 발하는 또 다른 영역은 스키마 검사입니다. GraphQL 은 스키마 검사를 주요 기능으로 정의하고 있습니다. 

 

예를 들어 GraphQL 의Root유형에는 쿼리에 사용할  있는 유형을 조사하는데 사용할 수 있는 __schema 필드가 있습니다:   

 

// GraphQL request
query {
  __schema {
    types {
      name
      description
      fields {
        name
      }
    }
  }
}
// JSON response
{
  "data": {
    "__schema": {
      "types": [
       { 
         "name": "Root",
         "description": null
       },
       {
          "name": "User",
          "description": "A user of the platform." 
          "fields": [
            { "name": "name" },
            { "name": "id" }          
          ]
        },
        {
          "name": "Organization",
          "description": "An organization of the platform." 
          "fields": [
            { "name": "name" },
            { "name": "id" }          
          ]
        }    
      ]
    }  
  }
}

 

SQL 공정하게 비교해보 GraphQL의 일부 내부 검사 쿼리는 끔찍할정도로 복잡하게 보일 수 있고 SQL 구문에 익숙하다면 위와 같은 내부 검사를 쉽게 표현할 수 있습니다.    

SELECT c.table_schema,c.table_name,c.column_name,pgd.description
FROM pg_catalog.pg_description pgd
  RIGHT JOIN information_schema.columns c on
    (pgd.objsubid=c.ordinal_position)
WHERE c.table_schema NOT IN ('pg_catalog', 'information_schema');

 

그러나 SQL 쿼리는 Postgres 데이터베이스에 종속된 특정 매개 변수로 가득 차 있습니다.(MySQL 데이터베이스를 사용한 한 쿼리는 다를 수 있습니다.) 또한 위의 쿼리는 일반 텍스트로 읽을  있을만큼 쉽게 쿼리를 보내고 응답을 을 수 있지만, 이를 위해서는 업체별 SQL 특징, 통신 프로토콜 , ODBC 또는 이를 조합하여 사용할  있는 업체별 CLI 클라이언트 또는 업체  데스크톱 GUI와 같은특수 도구 필요합니다. 

 

반면 GraphQL 은 내부 검사 쿼리를 포함한 모든 쿼리에 대해 HTTP를 통해 JSON 텍스트를 반환하므로 Postman, Chrome Dev Tools 또는 모든 Mac Linux OS 터미널 미리 설치된 간단한 curl 명령을 사용하여 엔드 포인트에서 쉽게 사용할 수 있습니다. 

 

결론 

REST 및 SQL의 많은 단점에 대한 해결 방법이 없는 것은 아닙니다. RESTful API로 오버 페칭  언더 페칭 문제를 해결하거나 엔드 포인트를 미리 정의하여 RESTful API에 스키마를 추가하려는 시도들도 있었습니다. SQL은 쿼리 언어일 뿐이므로 HTTP를 통해 일반 텍스트 CSV 또는 JSON 반환되는  많은 SQL 인터페이스를 구축하는  불가능한 것은 아닙니다. 그러나 이제 블록체인  주소 기반 컨텐츠 스토리지 네트워크가 활성화됨에 따라 조직의 신뢰 경계 넘어 직접 임의의 데이터를 효율적으로 쿼리하는것은 REST나 SQL의 DNA에 포함되지 않습니다. 

 

한편, GraphQL 은 처음부터  사용 목적을 염두에 두고 설계되었습니다. 고급 쿼리를 위한 사용자 친화적 GUI  GraphQL 쿼리 결과를 UI에 보여줄프런트 엔드 엔지니어를 염두에 두고 설계되었습니다. dApp이 주로 블록 체인에서 실행되는 스마트 계약과 인터페이스하는 브라우저 앱으로 구성된 상황에서 프론트 엔드 엔지니어의 요구와 선호에 따라 분산 웹 기술 스택이 결정될 것입니다. 이미 우리는Ethereum의 JSON RPC API 앞에 GraphQL 인터페이스 배치하려는 여러 시도들이 나타나는 것을 보고 있습니다.      

 

The Graph 소비자들의 사용자 경험 개선을 블록체인과 분산 웹의 보급을 위한 주요 과제 중 하나로 여기고 있습니다. 이것이 The Graph가 지난 7 월, 개발자가 GraphQL 인터페이스를 통해 분산 플리케이션에 대한 Ethereum 및 IPFS 데이터를 효율적으로 쿼리 할 수 ​​있도록 오픈 소스 인덱싱 서버를 지원하기 시작한 이유입니다. 앞으로 블록체인에서 데이터 과학 및 머신 러닝을 위한 분석이 흔해지면 The Graph는 SQL과 다른 쿼리 언어에 대한 지원도 검토할 계획을 가지고 있습니다.