PostgreSQL을 사용한 동적 API용 Hasura GraphQL 엔진 소개

일반적으로 지난 몇 년 동안 REST API는 빠르게 변화하는 기술 요구 사항을 처리하는 동안 유연하지 않다는 비판을 받았습니다. 돌이켜보면 많은 사람들이 GraphQL이 API 개발의 추가적인 유연성과 효율성에 대한 이러한 요구에 대처하기 위해 만들어졌다고 믿습니다. 따라서 REST API의 결함을 완화합니다. Facebook이 HTML5 응용 프로그램에서 보다 강력하고 기본 설정으로 전환한 결과 GraphQL은 지난 5년 동안 인기와 채택이 높아진 데는 그럴만한 이유가 있습니다. 이 블로그에서는 GraphQL 현상인 PostgreSQL에 대해 자세히 알아보고 나중에 Hasura GraphQL 엔진에 대해 자세히 소개합니다. 스니펫에서 Hasura GraphQL 엔진-PostgreSQL 관계 및 생태계.

GraphQL: 페이스북의 반란

많은 사람들이 GraphQL이 REST API에 대한 반항으로 만들어졌다고 생각하지만 이는 사실과 다를 수 있습니다. 아이러니하게도 Facebook의 내부 요구 사항을 충족하기 위해 만들어졌습니다. 원래 Facebook 팀에서 설계하고 오픈 소스로 제공한 GraphQL은 종종 데이터베이스 기술로 혼동됩니다. 본질적으로 오해에도 불구하고 GraphQL은 기술적으로 데이터베이스가 아닌 API용 쿼리 언어 입니다. 결과적으로 API 구축의 복잡성을 줄여 모든 요청을 단일 엔드포인트로 추상화합니다. 기존 REST API와 달리 GraphQL은 선언적입니다. 즉, 요청된 것이 무엇이든 반환됩니다. 컨텍스트를 조금 더 이해하기 위해 한 걸음 물러서서 REST API를 다시 방문해야 합니다.

REST 아키텍처

일반적으로 API는 소프트웨어 구성 요소가 상호 작용하는 방식을 지정하는 규칙, 루틴 또는 프로토콜입니다. REST(Representational State Transfer)는 기본적으로 모든 것이 '리소스'로 간주되는 웹 서비스 구현에 일반적으로 활용되는 API 설계 아키텍처입니다. 불행히도 RESTful 방법론은 일관되게 단일 리소스를 처리하는 것으로 제한되었습니다. 따라서 데이터가 필요하고 두 개 이상의 리소스(예: 게시물 및 사용자)에서 오는 경우 필요한 모든 것을 수집하려면 서버로 여러 번 이동해야 합니다. 또한 REST는 '오버' 및 '언더' 가져오기 문제에 직면했습니다. 특히 관련 리소스를 결합한 대규모 데이터 세트를 처리하는 데이터 중심 앱의 출현으로 이 모든 것이 이상적이지는 않았습니다. 이는 Facebook이 직면한 곤경을 설명할 수 있습니다.

따라서 보다 유연하고 진보적인 접근 방식을 취하는 API 아키텍처가 필요합니다.

대안의 창조

또는 GraphQL은 리소스 URL, 보조 키 또는 테이블의 관점에서 데이터를 생각하지 않고 NSObject 또는 JSON을 사용하는 개체 및 모델의 그래프 관점에서 데이터를 생각합니다. 특히 GraphQL은 다양한 기능과 사용 사례를 단일 "그래프"로 표현할 수 있으므로 사용 사례별로 전용 엔드포인트가 필요하지 않습니다. GraphQL 쿼리 언어를 사용하면 응답이 어떻게 생겼는지 정확하게 설명할 수 있으므로 추가 서버 왕복이 필요하지 않습니다. 애플리케이션 계층 쿼리 언어로서 서버/클라이언트의 문자열을 해석하고 해당 데이터를 안정적이고 이해 가능하며 예측 가능한 형식으로 반환하도록 설계되었습니다 . 데이터를 더 잘 통합하기 위한 도구일 뿐입니다.

단순성, 안정성 및 효율성.

진실은 잘 정의된 스키마에도 불구하고 모든 프로젝트에 GraphQL이 필요한 것은 아니므로 우리가 과도하게 가져오지 않을 것이라는 것을 확실히 알고 있습니다. 그러나 MySQL, Postgres 및 기타 API와 같은 여러 소스의 데이터에 의존하는 엔터프라이즈 제품이 있는 경우 GraphQL이 더 나은 옵션입니다. GraphQL은 데이터가 공통 엔드포인트 또는 호출에서 수집되기 때문에 특히 데이터 검색과 관련하여 단순성을 자랑합니다. 기본적으로 클라이언트는 정확히 필요한 것을 얻으므로 클라이언트가 수행하는 각 요청의 크기를 효과적으로 줄여 고성능 응용 프로그램을 만듭니다. GraphQL은 여러 엔드포인트가 필요한 데이터를 통합하므로 복잡한 반복 검색이 쉬워지고 쿼리 효율성이 향상됩니다. 결과적으로 단순함과 함께 더 많은 백엔드 안정성, 계획, 구축, 실행 및 시간이 지남에 따라 지속적인 운영이 가능합니다.

GraphQL의 장점

간단히 말해서, GraphQL을 사용하면 이해하기 쉬운 쿼리로 데이터를 추출할 수 있고, 서버를 통하지 않고 데이터에 더 직접 액세스하기 때문에 가볍고 빠른 애플리케이션을 빠르게 개발할 수 있습니다. 또한 모든 데이터에 대해 하나의 엔드포인트를 사용하면서 여러 URL이나 리소스 체인을 사용하지 않고 하나의 쿼리로 여러 리소스를 검색할 수 있습니다. 데이터는 그래프 기반 방식으로 서버에서 정의되므로 다중 호출이 아닌 패키지로 전달됩니다. 이를 통해 API 개발 중에 API 응답을 집계하는 작업이 향상됩니다.

이는 차례로 프런트 엔드 개발 팀의 부하를 줄이고 API 버전 관리를 용이하게 하며 유지 관리를 단순화하고 데이터 전송 요구를 절약합니다. 또한 데이터를 수신할 때 예측 가능성을 높이고 선언적 데이터 가져오기를 지원하며 오버페칭 및 언더페칭을 완화합니다. 기본적으로 오버페칭은 클라이언트가 앱에서 실제로 필요한 것보다 더 많은 정보를 다운로드할 때 발생하는 반면, 언더페치는 특정 엔드포인트가 충분한 정보를 제공하지 않아 클라이언트가 필요한 것을 가져오기 위해 추가 요청을 해야 함을 의미합니다.

기술적으로 GraphQL은 REST 시스템을 완전히 교체할 필요가 없음을 의미하는 정의할 수 있는 래퍼입니다. 본질적으로 이것은 GraphQL이 REST 중심 API와 호환되는 시스템과 호환된다는 것을 의미합니다. 또한 GraphQL을 사용하면 프론트 엔드와 백엔드를 원활하고 독립적으로 개발할 수 있습니다. 스키마가 잘 정의되면 프론트엔드와 백엔드에서 작업하는 팀 모두 데이터의 명확한 구조를 알고 있기 때문입니다. 이러한 모든 이점은 많은 풀 스택 엔지니어에게 유리한 것으로 간주됩니다. 마지막으로, GraphQL은 철저한 자기 성찰과 자체 문서화를 위한 놀라운 능력을 가지고 있습니다.

API 개발의 GraphQL 사용 사례

매우 강력한 것으로 간주되는 GraphQL은 빠른 속도와 인덱싱으로 안정적인 가독성을 원하는 전체 스택 개발자가 사용합니다. 특히 GraphQL은 높은 데이터 처리량이 필요한 API 개발에 유용합니다. 사실상 네트워크를 통한 전송에 필요한 데이터 양을 최소화합니다. 이것은 모바일 사용자, 저전력 장치 및 엉성한 네트워크에 매우 유용합니다. 이것이 Facebook이 GraphQL을 설계한 초기 이유 중 하나입니다. 생각과 달리 GraphQL은 거대하고 복잡한 데이터베이스에만 적용할 수 있는 것이 아니라 상대적으로 간단한 데이터베이스를 보다 효율적으로 생성할 수 있습니다.

또한 다양한 고유한 프론트 엔드 프레임워크 및 플랫폼에 적용할 수 있어 모든 사용자 요구 사항에 맞는 하나의 API로 유지 관리되는 이기종 환경을 제공합니다. 또한 전체 스택 개발자 팀의 기능 속도를 크게 향상시켜 빠른 기능 개발을 용이하게 합니다. 예를 들어 백엔드 개발자가 제공할 때까지 기다릴 필요 없이 새로운 기능을 도입하거나 기존 기능을 변경하기 위해 프런트 엔드 개발자가 API를 요청할 수 있으므로 새 기능을 개발하는 동안 팀 간에 필요한 커뮤니케이션을 줄임으로써 이를 수행합니다. 이 빠른 GraphQL 요약은 Hasura GraphQL 엔진에 대한 소개를 시작하는 지금으로 충분합니다. 조금 더 많은 컨텍스트를 위해 PostgreSQL을 만지자.

PostgreSQL이란 무엇입니까?

무료 커뮤니티 기반 관계형 데이터베이스 관리 시스템인 PostgreSQL은 단일 회사의 소유가 아닙니다. 사용 가능한 가장 강력하고 내부적으로 일관된 RDBMS로 간주되는 Postgres는 C로 작성되었으며 C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net 등과 같은 여러 프로그래밍 언어를 지원합니다. 전체 스택 개발자인 PostgreSQL은 자매 MySQL보다 기능이 더 풍부하여 기능, 확장성 및 성능으로 인해 인기를 얻고 있습니다. PostgreSQL은 요구 사항이 복잡한 절차, 복잡한 설계, 맞춤형 통합 및 데이터 무결성을 중심으로 하는 프로젝트에서 널리 사용됩니다.

풀스택 개발자를 위한 Postgres의 장점

일반적으로 전체 텍스트 검색, JSON 열, 논리적 복제와 같은 기능은 Postgres가 MySQL에서 우위를 점할 수 있도록 합니다. 이것은 오버헤드와 비용을 줄이기 위해 여러 데이터베이스 시스템을 하나로 통합하는 동시에 일반적인 상용 데이터베이스의 성능 요구에 최적입니다. 또한 Key-Value-Storage(JSON/JSONB 열 유형)에 대한 최신 기능으로 인해 NoSQL 데이터베이스에 대한 적절한 대안이 됩니다. 또한 클러스터링 또는 마스터-슬레이브 아키텍처를 지원하므로 클라우드와 같은 환경에 적합합니다. 또한 널리 사용되는 foreign-data-wrapper 확장 기능을 사용하면 필요할 때 PostgreSQL 내에서 직접 외부 소스를 쿼리할 수 있습니다. 특히 복잡한 쿼리 실행, 데이터 웨어하우징 및 동적 데이터 분석이 필요한 시스템에 가장 적합합니다.

사실 PostgreSQL은 MySQL이 지원하지 않는 특정 기능을 더 잘 지원합니다. 예를 들어 제약 조건, 다양한 데이터 유형(예: 배열, 지도, JSON), 보다 풍부한 지리 공간 지원(PostGIS) 및 보다 풍부한 전체 텍스트 지원을 확인하십시오. 또한 비차단 인덱스 생성, 부분 인덱스, 공통 테이블 표현식 및 보다 동적인 분석 기능을 지원합니다. 그럼에도 불구하고 PostgreSQL은 클라이언트/서버 통신의 암호화를 위한 연결에 대한 기본 SLL 지원과 SELinux 정책을 기반으로 추가 액세스 제어를 제공하는 SE-PostgreSQL이라는 기본 제공 향상 기능을 제공합니다.

엔터프라이즈급 제품을 위한 다양한 기능을 갖춘 PostgreSQL은 데이터 인증이 필요하고 읽기/쓰기 속도가 프로젝트 성공에 중요한 대규모 시스템에 적합합니다. 또한 일반적으로 독점 솔루션에서 사용할 수 있는 여러 성능 향상 장치도 지원합니다. 여기에는 읽기 잠금이 없는 동시성, SQL 서버 및 지리 공간 데이터 지원이 포함됩니다.

Postgres 아키텍처의 또 다른 주요 이점은 고유한 확장성입니다. 이를 통해 사용자는 핵심 시스템 코드를 변경하지 않고도 데이터 유형, 인덱스 액세스 방법, 서버 프로그래밍 언어, 외부 데이터 래퍼(FDW) 및 로드 가능한 확장과 같은 기능을 추가할 수 있습니다. 최신 멀티 코어 프로세서 아키텍처를 활용하므로 코어 수가 증가함에 따라 성능이 거의 선형으로 증가합니다. 이것은 중요합니다. 일반적으로 전체 텍스트 검색, JSON 열, 논리적 복제와 같은 기능은 Postgres가 MySQL에서 우위를 점할 수 있도록 합니다. 이것은 오버헤드와 비용을 줄이기 위해 여러 데이터베이스 시스템을 하나로 통합하는 동시에 일반적인 상용 데이터베이스의 성능 요구에 최적입니다. 또한 Key-Value-Storage(JSON/JSONB 열 유형)에 대한 최신 기능으로 인해 NoSQL 데이터베이스에 대한 적절한 대안이 됩니다. 또한 클러스터링 또는 마스터-슬레이브 아키텍처를 지원하므로 클라우드와 같은 환경에 적합합니다. 또한 널리 사용되는 foreign-data-wrapper 확장 기능을 사용하면 필요할 때 PostgreSQL 내에서 직접 외부 소스를 쿼리할 수 있습니다. 특히 복잡한 쿼리 실행, 데이터 웨어하우징 및 동적 데이터 분석이 필요한 시스템에 가장 적합합니다.

PostgreSQL의 단점

일반적으로 ANSI SQL 표준을 선호한다면 PostgreSQL을 고려하고 ODBC 표준을 선호한다면 MySQL을 선택하십시오. 불행히도 Postgres는 "항상 가동되는" 라이브 프로덕션 환경에서 성능이 떨어지는 경우가 있습니다. Postgres의 또 다른 단점은 복제가 스토리지 엔진 수준에서 구현된다는 사실입니다. 이것은 "쿼리 엔진 수준"에서 더 성숙하고 구현되는 MySQL의 복제보다 비용이 많이 듭니다.

Hasura GraphQL 엔진 소개

GraphQL API 개발 및 PostgreSQL에 대해 간략하게 다루었으므로 Hasura GraphQL 엔진을 소개하기에 충분한 컨텍스트가 있어야 합니다. 기본적으로 Hasura는 단순히 PostgreSQL RDBMS용 GraphQL 엔진으로, GraphQL API 개발을 부트스트랩하고 관리하는 단순화된 방법을 제공합니다. 돌이켜보면 Hasura는 현재 기존 PostgreSQL 기반 애플리케이션에 GraphQL-as-a-Service를 즉시 추가할 수 있는 유일한 솔루션입니다. 본질적으로 GraphQL을 처리하는 백엔드 코드를 작성하는 시간 소모적인 작업을 우회합니다.

하수라 간체

잠시 시간을 내어 Hasura를 더 단순화해 보겠습니다. 기본적으로 API는 정보(쿼리)를 요청하고 JSON 또는 XML 데이터를 전송하여 응답할 수 있는 인터페이스입니다. 해당 데이터베이스는 일반적으로 서버에서 호스팅되고 페치됩니다. 여기에서 Hasura가 일을 단순화합니다. 돌이켜보면 Hasura GraphQL 엔진은 Postgres 데이터베이스를 통해 GraphQL 쿼리를 처리하는 서버입니다. 이를 통해 앱이 프로덕션 준비가 되는 데 걸리는 시간을 효과적으로 줄여 몇 번의 클릭만으로 데이터베이스 테이블을 쉽게 생성, 확인 및 수정할 수 있습니다. 결과적으로 이를 통해 전체 스택 개발자는 더 짧은 시간 내에 PostgreSQL에서 확장 가능한 GraphQL 애플리케이션을 구축할 수 있습니다. 이를 통해 개발자는 사전 코딩에 몇 주간의 시간을 절약할 수 있으며 문제가 있는 데이터 누출 버그가 프로덕션 단계로 넘어가는 것을 방지할 수 있습니다.

API 개발에서 Hasura는 어떤 문제를 해결하고 있습니까?

일반적으로 Hasura는 특히 복잡한 API에 대한 대규모 생산 사용 중에 API 수명 주기 관리를 단순화합니다. 무엇보다 GraphQL 엔진은 기존 PostgreSQL 데이터베이스를 활용하는 엔터프라이즈 API 개발 프로젝트로 백로그된 풀 스택 개발자를 끌어들입니다. 이상적으로는 GraphQL이 번개처럼 빠른 API 개발 주기를 허용하므로 Hasura는 조직이 기존 애플리케이션, 데이터베이스 또는 사용자에 영향을 주지 않고 점진적으로 GraphQL로 이동할 수 있는 간소화된 방법을 제공합니다. 가볍고 고성능일 뿐만 아니라 엔진에는 관리 UI가 함께 제공되므로 GraphQL API를 탐색하고 데이터베이스 스키마와 데이터를 시각적으로 관리할 수 있습니다.

하수라의 장점

첫째, Hasura는 데이터베이스 변경 또는 "마이그레이션"을 관리하기 위한 견고하고 안정적인 모델을 가지고 있습니다. 이것은 데이터베이스 스키마 관리가 종종 까다롭기 때문에 유리합니다. 예를 들어, 다음과 같은 작업; 시간 경과에 따른 변경 추적 및 API 향상(스키마 관리)과 스키마 변경 연결. 또한 새로운 데이터베이스를 배포하거나 변경 사항을 롤백할 수 있는 스크립트 유지 관리와 같은 일상적인 작업은 지루하고 진단하기 어려운 버그 또는 중단을 유발할 수 있습니다. 긍정적인 측면에서 Hasura 데이터베이스 마이그레이션 구성 요소는 일반 SQL이므로 Hasura 도구 집합 외부에서 이식 가능합니다. 대체로 Hasura에는 훌륭한 스키마 관리 기능이 있으며 웹 소켓 연결을 처리하기 위해 코드를 작성할 필요가 없습니다.

둘째, Hasura GraphQL 엔진을 사용하면 단일 쿼리로 필요한 데이터를 쉽게 가져올 수 있습니다. 이는 테이블이나 다른 보기에 대한 관계로 보기를 추가할 수 있도록 하여 수행합니다. 또한 데이터베이스 이벤트에서 트리거되는 서버리스 기능 또는 마이크로 서비스 API의 스키마 스티칭 및 통합을 사용하여 사용자 지정 해석기를 작성할 수 있습니다. 이것은 유용할 수 있고 3factor 앱 구축을 용이하게 합니다. 사실 Hasura는 매우 가벼운 엔진입니다. 돌이켜보면 초당 1000개 이상의 요청을 처리하는 동안에도 최대 50MB의 RAM만 소비합니다. 눈부신 투자수익률!

특히 Hasura는 세분화된 API 데이터 수준 권한 부여 및 인증을 더욱 용이하게 합니다. 웹훅, JWT, Auth0 또는 사용자 정의 구현을 통해 선호하는 인증 제공자에 연결할 수 있습니다. 따라서 관리자, 익명 사용자 등과 같이 다른 데이터에 액세스할 수 있는 사용자를 정의하는 사용자의 역할을 지정합니다. 일반적으로 세분화된 액세스 제어 시스템은 GraphQL 스키마와 유사한 데이터베이스 테이블 구조를 기반으로 합니다. 또한 사용자 지정 권한 규칙은 데이터베이스 작업 및 값을 기반으로 엄격하게 정의됩니다.

마지막으로 Hasura는 간단한 SQL과 같은 오프셋/제한 모델로 효율적인 페이징을 훌륭하게 지원합니다. 예를 들어, 액세스 제어 모델을 사용하여 주어진 쿼리에 대해 반환되는 행 수를 제한합니다. 그 모델은 역할별로 한계를 조정할 수 있습니다. 예를 들어, 훨씬 더 높은 요청 비율을 부과하는 사용자는 더 작은 행 제한으로 제한됩니다. 이렇게 하면 데이터베이스와 GraphQL 엔진에 스트레스를 주지 않습니다. 또한, 특히 Hasura는 사용자를 GraphQL로만 제한하지 않습니다. Hasura가 관리하는 Postgres 테이블에 대해 REST 또는 기타 비 GraphQL 마이크로 서비스를 계속 실행할 수 있습니다. 이것은 Hasura의 자동 스키마 스티칭으로 가능합니다. 이를 통해 새로운 Hasura 관리 API를 레거시 API 및 데이터와 결합하여 단일 통합 스키마에 대한 비 Hasura GraphQL 서비스 및 백엔드를 병합할 수 있습니다.

하수라 사용 사례

고성능 환경에 적합한 Hasura 엔진은 기존 데이터베이스에서 GraphQL-Postgres 구현을 자동화하면서 속도를 제공합니다. 결과적으로, 이것은 이미 Postgres를 사용하고 있는 기업에게 기존 테이블을 "그래프"로 연결함으로써 GraphQL로 이전하는 스트레스가 덜하고 점진적인 방법을 제공합니다. Hasura는 사용자 정의 비즈니스 로직을 쉽게 적용할 수 있도록 스키마 스티칭을 효율적으로 처리합니다. 원격 GraphQL 스키마를 사용하면 Hasura를 사용자 지정 비즈니스 로직을 위한 게이트웨이로 활용하여 원하는 언어로 GraphQL 서버에 작성한 다음 나중에 데이터를 단일 엔드포인트에 노출할 수 있습니다. 또한 Hasura는 GraphQL의 구독이라고 하는 내장 라이브 쿼리를 사용하여 쿼리 및 변형을 위한 훌륭한 구문을 가지고 있습니다.

몇 가지 Hasura 제한 사항

불행히도 Hasura의 액세스 제어 시스템 모델은 모든 애플리케이션에서 완전히 작동하지 않습니다. 예를 들어 개별 입력 매개변수 수준에서 API 액세스 권한을 완전히 지원하지 않습니다. 대부분의 경우 마이그레이션이 필요한 Postgres 데이터베이스로 제한된다는 사실은 말할 것도 없습니다. 무시해도 되지만 잘못된 형식의 요청에 대해 GraphQL API가 반환하는 오류 메시지는 Hasura에서 매우 비우호적입니다. 그렇지 않으면 이 Hasura GraphQL Engine 소개에서 보았듯이 Hasura가 할 수 없는 것이 거의 없습니다.

결론

결론적으로 GraphQL이 성장함에 따라 웹 규모에서 구축하기 위해 기업 내 API 개발을 본질적으로 더욱 단순화할 것입니다. 다양한 산업군에서 GraphQL을 광범위하게 빠르게 채택하면서 Hasura는 선택한 산업 표준 기술인 GraphQL 및 Postgres를 사용하여 API 생성 및 관리를 더욱 자동화할 수 있는 잠재력을 가지고 있습니다. Hasura 는 CRUD(생성, 읽기, 업데이트 및 삭제) GraphQL 백엔드 생성을 단순화합니다. 더 중요한 것은 Hasura가 백엔드 코드를 작성하지 않고 GraphQL 중심 API 및 Postgres로 처음부터 시작하는 경우 단연 최고이자 유일한 옵션이라는 것입니다. GraphQL 및 Hasura 엔터프라이즈 가능성에 대한 질문이나 상담이 있으면 언제든지 저희에게 연락하십시오. 여기까지 Hasura GraphQL Engine을 소개합니다.