그래프 QL 게이트웨이 구축 : 모든 데이터 소스를 결합, 스티치 또는 병합하십시오.-JS 튜토리얼-php.cn

Build a GraphQL Gateway: Combine, Stitch or Merge any Datasource

코어 포인트

GraphQL 게이트웨이는 기존 API 게이트웨이와 그래프QL의 장점을 결합하여 소프트웨어 엔지니어가 프론트 엔드 효율을 유지하면서 여러 데이터 소스에서 데이터를 얻을 수 있습니다.

백엔드, 즉 프론트 엔드 (BFF) 아키텍처 패턴은 프론트 엔드의 요청 수를 줄여 API 게이트웨이에 단일 요청을 허용하여 프로세스를 단순화 한 다음 각 백엔드 서비스에서 데이터를 가져옵니다. 결합합니다.

GraphQL은 효율적인 데이터 수집, 모든 요청에 대한 단일 엔드 포인트 및 프론트 엔드가 각 요청에 필요한 데이터 만 선택할 수있는 유연한 쿼리를 포함하여 많은 장점을 BFF에 제공합니다.

GraphQL 게이트웨이 설정을위한 권장 프레임 워크에는 Hasura, Stepzen 및 GraphWeaver가 포함됩니다. 이러한 프레임 워크는 여러 데이터 소스 연결, 라우팅, 배치 처리, 보안, 크로스 데이터 소스 필터링 및 확장 성과 같은 여러 기능을 제공합니다.

이 기사는 프론트 엔드 응답을 신속하게 유지하면서 여러 데이터 소스에서 데이터를 가져 오는 방법과 GraphQL 게이트웨이를 사용하는 잠재적 솔루션을 논의합니다.

우리는 소프트웨어 엔지니어로서 여러 시스템에서 데이터를 구성 해야하는 과제에 직면 해 있습니다. 단일 페이지조차도 여러 서비스의 데이터를 렌더링해야합니다.

데이터는 CRM에서 금융 시스템, SAAS 플랫폼에서 데이터베이스에 이르기까지 어디에나 있습니다. 모든 비즈니스가 많은 SaaS 플랫폼을 구매 한 다음 모든 비즈니스에서 통일 된 비즈니스보기를 얻을 수 있기를 바랍니다. 우리는이 문제에 직면하고 모든 것을 정리해야합니다.

GraphQL 게이트웨이는 기존 API 게이트웨이와 그래프 QL의 장점을 결합합니다.

우리는 먼저 API 게이트웨이의 장점에 대해 논의한 다음 GraphQL이 어떻게 맞는지 확인합니다. 이 기사를 계속 읽으십시오. 우리는 자체 API 게이트웨이를 구축하기위한 프레임 워크를 다룰 것입니다.

API 게이트웨이의 장점

해커로부터 공개 API를 보호하는 것은 전천후 직업입니다. 시간이 지남에 따라 조직은 서비스 지향 아키텍처에서 마이크로 서비스에 이르기까지 많은 API를 만들도록 진화했습니다. 조직은 이러한 API를 인터넷에 직접 배치하는 대신 추가 보안 계층을 추가하는 경향이 있습니다.이 API는 이러한 모든 API보다 앞서 있으며 데이터에 대한 액세스는 항상 동일한 인증 규칙을 따릅니다.

그들은 API 게이트웨이를 사용하여이를 수행합니다.

Kong 또는 Apigee와 같은 제품은 중앙 위치에서 내부 API를 노출시킵니다. API 키 관리, 요금 제한 및 모니터링과 같은 기능을 갖춘 역전 프록시 역할을합니다.

API 게이트웨이를 사용하면 각 서비스에 액세스하고 연결을 모니터링하며 액세스를 기록 할 수있는 사람과 대상을 제어 할 수 있습니다.

최근에 응용 프로그램은 API 게이트웨이 및 기타 외부 SAAS 제공 업체의 데이터를 결합해야합니다. 이는 이전 중앙 집중식 도구 (우리의 규칙을 준수해야 함)가 이제 정기적으로 우회되었음을 의미합니다.

우리가 회사를위한 웹 애플리케이션을 구축하고 있다고 가정합니다. 우리의 임무는 사용자 프로필 페이지를 만드는 것입니다. 로그인 프로세스 중에 여러 시스템의 데이터를 결합해야합니다.

Salesforce CRM : 표정 및 성과 같은 일반 고객 데이터를 저장합니다.

주문 : 가장 최근의 주문 단위는 조직 내에서 주문 시스템에 있습니다.

알림 서비스 : 알림 설정 및 최근 메시지는 Node.js 서비스에 연결된 응용 프로그램 별 데이터베이스에 있습니다.

클라이언트는 아래 그림과 같이 데이터를 얻기 위해 세 가지 별도의 요청을 발행해야합니다.

위의 이미지에서 웹 클라이언트는 세 가지 별도의 API 요청을 보내고 결과를 프론트 엔드 코드로 결합해야합니다. 여러 요청을 보내면 응용 프로그램의 성능에 영향을 줄 수 있으며이 데이터를 결합하면 코드의 복잡성이 증가 할 수 있습니다. 또한 여러 응용 프로그램이있는 경우 모든 응용 프로그램이 모든 백엔드에 대해 알아야하며 서비스의 단일 API 변경으로 인해 모든 응용 프로그램에 대한 업데이트가 발생할 수 있습니다.

우리는 더 잘할 수 있습니다. 이상적으로는 요청을 3에서 1로 줄이려고합니다. 백엔드 서비스 요청을 조정하는 서비스 인 새로운 서비스를 만들 수 있습니다. 이 아이디어에는 이름이 있습니다 : BFF 모드.

백엔드, 즉 프론트 엔드 (BFF) 아키텍처 모드를 사용하면 프론트 엔드가 단일 요청을 발행 할 수 있습니다.

그러나 어떻게 작동합니까? 이 패턴을 자세히 살펴 보겠습니다. Build a GraphQL Gateway: Combine, Stitch or Merge any Datasource BFF 모드의 장점

BFF 모드를 사용하여 응용 프로그램은 API 게이트웨이에 단일 요청을 보냅니다. 그런 다음 BFF 서비스는 각 백엔드 서비스에서 데이터를 요청하고 결합합니다. 마지막으로, 데이터가 필터링되고 프론트 엔드에 필요한 데이터 만 반환하여 네트워크를 통해 전송되는 데이터의 양이 줄어 듭니다.

위의 이미지에 표시된 것처럼, 우리는 요청을 조정하기 위해 스택에 추가 레이어를 소개합니다.

사용자 프로파일 엔드 포인트는 프로필 페이지의 응용 프로그램에서 요구하는 데이터를 반환합니다. 세 가지 요청을 하나로 줄이면 이전 성능 문제가 해결되었습니다.

그러나 우리는 아직 끝나지 않았습니다.

기업은 모바일 앱을 출시하기로 결정합니다. 모바일 앱에는 프로필 페이지도 있지만이 화면에는 프로필 정보가 훨씬 적습니다.

이 시점에서 모바일 팀에는 두 가지 옵션이 있습니다. 팀은 웹 팀의 엔드 포인트를 사용할 수 있으므로 데이터를 과도하게 페치합니다 (모바일 앱에 필요한 더 많은 데이터를 얻습니다). 또 다른 옵션은 모바일 팀에서 자신의 BFF를 만드는 것입니다.

기대에 따르면, 모바일 팀은 응용 프로그램에 대한 좋은 성능을 원했기 때문에 자신의 BFF를 만들기로 결정했습니다.

위 그림에서 볼 수 있듯이 상황이 복잡해지기 시작했으며 이제 두 가지 새로운 문제가 있습니다.

각 팀은 그들이 만든 각 응용 프로그램에 대한 새로운 BFF 서비스를 만들어야하므로 각 팀이 느려지고 표준화하기가 어렵습니다.

각 BFF는 안전을 보장하기 위해 침투 테스트가 필요합니다.

이러한 문제를 어떻게 해결합니까?

각 응용 프로그램이 필요한 데이터를 선택할 수있는 솔루션이 필요하며 회사의 모든 응용 프로그램에서 사용하는 단일 API 여야합니다.

BFF가 성숙함에 따라 많은 개발자들이 휴식 대신 그래프 QL을 사용하려고 시도했습니다.

이 기술이 어떻게 도움이 될 수 있는지 봅시다.

bff 를 통한 GraphQL의 장점 GraphQL에는 BFF에 이상적인 기술이되는 많은 장점이 있습니다.

효율적인 데이터 수집. GraphQL을 사용하면 클라이언트가 필요한 데이터를 정확하게 요청할 수 있습니다. 이는 API에서 전송 된 데이터를 줄임으로써 성능을 향상시킵니다.

<.> 단일 엔드 포인트. GraphQL은 게이트웨이를 통해 많은 엔드 포인트를 노출시키는 대신 모든 요청에 단일 엔드 포인트를 사용합니다. 이는 유지 보수 및 버전 제어의 필요성을 단순화합니다.

유연한 쿼리. 클라이언트는 필드와 관계를 단일 요청으로 결합하여 쿼리를 구축 할 수 있습니다. 이를 통해 프론트 엔드 개발자는 데이터 수집을 최적화하여 성능을 향상시킬 수 있습니다. 또한 프론트 엔드 변경의 요구 사항이 변경되면 어떤 식 으로든 백엔드를 변경하지 않고 다른 데이터를 얻도록 업데이트 할 수 있습니다.

프런트 엔드는 이제 각 요청에 필요한 데이터 만 선택할 수 있습니다.

이제 두 개의 응용 프로그램을 동일한 GraphQL Server에 연결하여 두 번째 BFF 서비스의 필요성을 줄일 수 있습니다.

이제 우리는 조직의 모든 응용 프로그램에 대해 BFF를 공유 할 수 있습니다. 또한 침투를 테스트 해야하는 단일 종점이 있습니다.

그러나 우리는 또 다른 새로운 문제를 소개했습니다! 우리는 여전히 API 게이트웨이와 GraphQL BFF의 두 가지 시스템을 관리해야합니다.

두 사람을 그래프 QL 게이트웨이로 병합하면 어떻게됩니까?

GraphQL 게이트웨이는 API 게이트웨이를 GraphQL API와 결합하여 두 기술의 최상의 결과를 얻습니다.

장점을 검토합시다

개발자는 데이터를 요청하기위한 단일 API 엔드 포인트를 가지고 있습니다. 각 응용 프로그램은 필요한 데이터 만 선택하므로 과도하거나 불충분 한 페치를 줄입니다.

GraphQL 게이트웨이는 조직의 많은 응용 프로그램에서 공유됩니다. 이는 단일 API 엔드 포인트로 보안 위험을 줄였습니다.

우리는 이제 BFF가 게이트웨이와 병합되어 관리 및 배포 해야하는 하나의 서비스 만 있습니다.

다음 이미지는 사용자 프로파일 API 요청이 GraphQL 게이트웨이와 함께 작동하는 방법을 보여줍니다.

위의 이미지에서 클라이언트는 단일 요청을 GraphQL 게이트웨이로 보냅니다. 필요한 데이터를 요청합니다. 게이트웨이는 각 서비스에 단일 요청을 발행하고 결과를 결합합니다. 이제 관리 및 배포 해야하는 서비스가 하나뿐입니다.

나는 당신이 직접 시도해 볼 준비가 되었기를 바랍니다. 다음으로 GraphQL 게이트웨이를 구축하는 방법을 살펴 보겠습니다.

빌드 그래프 QL 게이트웨이

게이트웨이 프레임 워크를 선택할 때는 몇 가지 주요 기능을 찾아야합니다.

여러 데이터 소스. 게이트웨이는 데이터베이스에서 SaaS에 이르기까지 많은 데이터 소스에 연결되어 있어야합니다. 우리는 연결을 만들 수 있어야합니다. 경로. 게이트웨이는 기본 서비스에서 직접 데이터를 요청할 수 있어야합니다.

배치 처리. 동일한 서비스로 전송 된 여러 쿼리가 배치로 전송되어 요청 수가 줄어 듭니다.

안전합니다. 인증 및 승인은 연결된 데이터에 액세스 할 수있는 사람을 제어해야합니다.

데이터 소스를 가로 지르는 필터. 클라이언트가 요구하는 데이터를 과도하게 구입하지 않도록 강력한 필터가 제공되어야합니다.

확장 성. 개발자는 자신의 요구를 충족시키기 위해 미들웨어 또는 기능을 사용하여 코드를 확장 할 수 있어야합니다.

선택할 수있는 많은 프레임 워크가 있지만 다음 세 가지 프레임 워크를 더 탐색하는 것이 좋습니다.

hasura

우리는 다른 서버의 GraphQL을 결합한 "원격 모드"에 연결할 수 있습니다.

이 방법에는 몇 가지 단점이 있습니다. 먼저 별도의 서비스에서 원격 스키마를 생성하고 관리해야 하며이 서비스는 그래프 QL 엔드 포인트 여야합니다. 이것은 두 번째 문제로 이어집니다. 데이터 소스에 직접 연결할 수 없습니다.

또한 Hasura는 다른 데이터 소스의 값을 기반으로 한 데이터 소스에서 데이터를 필터링 할 수 없습니다. 이것은 학문적으로 들릴지 모르지만 우리는 종종“ABC”라는 이름의 주문을 제공하고 싶습니다.

이것은 유연성을 제공하지만 여러 서비스를 실행하는 데 드는 비용으로 제공됩니다. 직접 연결할 수있는 옵션을 살펴 보겠습니다.

스테 젠 stepzen을 사용하면 GraphQL Server의 데이터 소스에 직접 연결할 수 있습니다. 이로 인해 게이트웨이를 만들기 위해 여러 서비스를 실행해야 할 필요성이 줄어 듭니다.

Stepzen을 데이터 소스에 연결하려면 아래 그림과 같이 GraphQL Schema 파일을 만듭니다.

이 예에서는 사용자 정의 모드를 사용하여 서버를 데이터베이스에 연결합니다.

그래프 weaver

지난 몇 년 동안 나는 GraphQL 게이트웨이로 사용할 수있는 GraphWeaver라는 오픈 소스 제품을 개발해 왔습니다.

데이터 소스에 직접 연결하고 즉각적인 그래프 QL API를 만듭니다. 이 API에는 생성, 읽기, 업데이트 및 삭제가 예상되는 모든 CRUD 작업이 포함되어 있습니다. 필터, 정렬 및 페이징 매개 변수를 자동으로 생성하여 시간을 절약합니다. 완벽한 유연성을 위해 코드로 내장 작업을 확장 할 수 있습니다.

GraphWeaver는 Xero 및 Contentful과 같은 SaaS 제공 업체뿐만 아니라 Postgres 및 MySQL과 같은 데이터베이스를 위해 데이터 커넥터를 상자에서 제공합니다.

변경 또는 데이터 소스에 연결하려면 TypeScript 코드를 작성하여 전체 사용자 정의를 수행 할 수 있습니다.

자신의 그래프 QL API를 작성하는 데 관심이 있으시면 그래프 워버 github 코드를 확인하는 것이 좋습니다.

결론

이 기사에서는 현재 API 게이트웨이 및 BFF 패턴을 단일 그래프 QL 게이트웨이로 교체하는 방법을 조사합니다.

우리는 API 게이트웨이의 장점과 조직이 사용하는 이유를 조사했습니다. 버전 작성, 요금 제한 및 액세스 관리는 몇 가지 이유입니다.

우리는 또한 BFF 패턴과 그것이 프론트 엔드 애플리케이션에 대한 API 요청을 조정하는 방법을 살펴 보았습니다. 마지막으로, 우리는 GraphQL을 보았고 왜 그것이 BFF에게 유익한 기술인지를 보았습니다. 하루 종일, 이로 인해 GraphQL 게이트웨이를 만들었고, 우리는 Hasura, Stepzen 및 제품 Graphweaver의 세 가지 옵션을 살펴 보았습니다.

이 기사가 GraphQL 게이트웨이를 직접 사용해 보도록 설득하고, 가능하다면 그래프 워버를 시도하는 것을 고려할 수 있기를 바랍니다.

GraphQL 게이트웨이 FAQ (FAQ)

GraphQL 게이트웨이의 주요 목적은 무엇입니까?

GraphQL 게이트웨이는 모든 GraphQL 작업에 대한 단일 진입 점 역할을합니다. 요청을 해당 서비스로 라우팅하고 응답을 집계하고 클라이언트로 다시 보냅니다. 이를 통해 단일 위치에서 여러 그래프 QL 패턴 및 서비스를 관리 할 수 있으므로 응용 프로그램을보다 확장 가능하고 유지 관리하기 쉽습니다.

GraphQL 게이트웨이와 기존 API 게이트웨이의 차이점은 어떻습니까?

기존 API 게이트웨이는 RESTFul API를 처리하도록 설계되었으며 작동 모드는 GraphQL과 다릅니다. 반면, GraphQL 게이트웨이는 GraphQL 작업을 처리하도록 특별히 설계되었습니다. 여러 그래프 QL 패턴을 하나로 결합 할 수있는 패턴 스티칭 및 병합과 같은 기능을 제공합니다. 이것은 전통적인 API 게이트웨이가 할 수없는 일입니다.

GraphQL 게이트웨이의 패턴 스 플라이 싱은 무엇입니까?

모드 스티치는 GraphQL 게이트웨이의 기능으로 여러 그래프 QL 패턴을 하나로 결합 할 수 있습니다. 이는 여러 서비스가 있고 각각 고유 한 스키마가있을 때 특히 유용하며 단일 API로 노출하려고합니다. Pattern Stitching은 패턴을 병합하고 충돌을 해결하여 클라이언트에게 완벽한 경험을 제공합니다.

GraphQL 게이트웨이는 성능을 어떻게 향상 시키는가?

GraphQL 게이트웨이는 클라이언트와 서버 간의 라운드 트립 수를 줄임으로써 성능을 크게 향상시킬 수 있습니다. 다른 서비스에 여러 요청을하는 대신 클라이언트는 단순히 GraphQL 게이트웨이에 단일 요청을 한 다음 요청을 해당 서비스로 라우팅하고 응답을 집계하고 클라이언트로 다시 보냅니다. 이는 네트워크 대기 시간을 줄이고 전반적인 성능을 향상시킵니다.

마이크로 서비스에서 GraphQL 게이트웨이를 사용할 수 있습니까?

예, GraphQL 게이트웨이는 마이크로 서비스 아키텍처에 특히 적합합니다. 각 마이크로 서비스는 자체 그래프 QL 패턴을 가질 수 있으며, 게이트웨이는 통합 된 API를 제공하기 위해 함께 연결될 수 있습니다. 이를 통해 고객에게 일관된 인터페이스를 제공하면서 마이크로 서비스를 독립적으로 관리하고 스케일 할 수 있습니다.

GraphQL 게이트웨이는 모든 프로그래밍 언어와 호환됩니까?

GraphQL 게이트웨이에는 언어가 없으므로 GraphQL을 지원하는 모든 프로그래밍 언어와 함께 사용할 수 있습니다. 여기에는 JavaScript, Python, Ruby 및 Java와 같은 인기있는 언어가 포함됩니다.

GraphQL 게이트웨이는 어떻게 오류를 처리합니까?

GraphQL 게이트웨이는 강력한 오류 처리 기능을 제공합니다. 서비스 중 하나에서 오류가 발생하면 게이트웨이는 어떤 서비스가 발생한 오류 및 발생 오류에 대한 정보를 포함하여 자세한 오류 메시지를 클라이언트에게 반환합니다. 이것은 문제를 더 쉽게 진단하고 해결할 수있게합니다.

서버리스 아키텍처에서 GraphQL 게이트웨이를 사용할 수 있습니까?