이번 글에서는 GraphQL 통합 방법에 대해 알아보겠습니다. Enterprise Solution 기준으로 설명드릴 예정이니 이 부분을 참고하시면서 보시면 되겠습니다. GraphQL에 대한 전반적인 내용이 궁금하시면 아래 글을 먼저 참고하세요.
GraphQL 사용 이유 (Feat. GraphQL 장점)
이 섹션에서는 통합된 GraphQL 아키텍처의 이점과 일반적인 통합 그래프를 통해 이러한 이점을 실현하는 방법에 대해 알아봅니다. Apollo에서 다양한 기업과 함께 일한 경험을 바탕으로 조직이 그래프를 통합할 준비가 되었는지 여부를 결정하기 위한 프레임워크도 제공합니다.
GraphQL을 통합해야 하는 이유?
GraphQL 커뮤니티와 관련 소프트웨어의 생태계는 놀라운 속도로 성장했습니다. 2015년 공개 릴리스 이후 몇 년 동안 이 GraphQL은 거의 모든 애플리케이션 아키텍처의 구성 요소로 사용할 수 있는 수준까지 빠르게 발전했습니다.
Airbnb, GitHub 및 New York Times와 같은 회사는 이미 기술 스택에 GraphQL을 채택한 것으로 유명합니다. 강력한 유형 시스템과 데이터 가져오기에 대한 선언적 접근 방식을 통해 기업 전체의 팀이 GraphQL의 많은 이점을 기꺼이 수용한 이유를 쉽게 알 수 있습니다. Apollo에서 매주 150만 회 이상의 Apollo 클라이언트 패키지 다운로드와 매주 수백만 건 이상의 Apollo 서버, 페더레이션 및 게이트웨이 패키지 다운로드를 통해 GraphQL에 대한 팀의 열정을 직접 확인할 수 있습니다.
회사의 여러 팀을 스캔하면 오늘날 많은 팀이 이미 프로덕션에서 GraphQL을 사용하고 있음을 금방 알 수 있습니다. 회사 전체에서 GraphQL이 사용되는 방식에 대한 최상위 수준의 통찰력을 갖는 것은 이러한 노력을 통합할 수 있고 통합해야 하는지 이해하기 위한 첫 번째 단계입니다.
GraphQL을 잘 활용하려면?
개발자가 GraphQL을 실험하기 시작할 때 클라이언트 애플리케이션이 단일 GraphQL 서버를 쿼리하는 기본 아키텍처로 시작하는 경우가 많습니다. 차례로 서버는 이러한 요청을 백업 데이터 원본에 배포하고 클라이언트가 원하는 형태로 데이터를 반환합니다.
여러 팀이 GraphQL을 채택하기 시작하면 접근 방식은 일반적으로 이 기본 아키텍처에서 조정되지만 구현 세부 사항은 팀마다 다를 수 있습니다. Apollo에서 우리는 일반적으로 이러한 초기의 통합되지 않은 노력이 다음 네 가지 패턴 중 하나와 유사하다는 것을 보았습니다.
Client-only인 경우?
GraphQL의 클라이언트 중심 데이터 가져오기 기능의 이점을 얻고자 하는 클라이언트 팀은 미리 비용을 청구하고 애플리케이션 컨텍스트 내에서 GraphQL API를 구현할 수 있습니다. 이러한 구현을 통해 이러한 팀은 단일 GraphQL API 끝점으로 기존 API를 래핑하는 편의를 위해 종종 GraphQL을 채택하도록 동기를 부여받습니다.
Front-end를 고려한 Back-end 설계
GraphQL은 BFF(Backend for Frontend) 패턴을 구현하는 팀을 위한 솔루션으로도 사용될 수 있습니다. BFF는 모놀리식 범용 API와 상호 작용하기 위해 서로 다른 클라이언트(예: 웹 및 iOS)를 요구하는 문제를 해결하려고 시도합니다. 또는 BFF는 특정 사용자 인터페이스 보기를 렌더링하는 데 필요한 모든 데이터를 얻기 위해 클라이언트 애플리케이션이 여러 백엔드 서비스에 요청하지 않도록 저장할 수 있습니다.
솔루션으로 BFF는 각 클라이언트가 클라이언트의 요청을 직접 수신하고 해당 사용자 경험과 밀접하게 연결된 전용 BFF 서비스를 갖는 새로운 계층을 추가합니다. BFF 서비스를 만드는 팀의 경우 GraphQL은 클라이언트 중심의 중개 계층을 구축하는 데 자연스럽게 적합할 수 있으며 이 패턴을 채택하는 것이 그래프 통합을 위한 중요한 첫 단계가 될 수 있습니다.
Monolith (모노리스 패턴)
모노리스 패턴은 두 가지 형태를 취할 수 있습니다. 첫 번째 형식에서 팀은 하나 이상의 클라이언트에서 사용하는 GraphQL 서버에 대해 하나의 코드베이스를 공유할 수 있습니다. 어떤 경우에는 클라이언트 코드가 GraphQL 서버와 동일한 리포지토리에 있을 수도 있습니다. 코드가 어떻게 구성되든 그래프에 기여하는 여러 개발자가 이 그래프의 소유권을 공유합니다.
대체 형식으로 단일 팀이 여러 클라이언트 팀에서 액세스하는 GraphQL API를 소유할 수 있습니다. 이 팀은 일반적으로 그래프에 대한 일련의 표준을 정의하고 조직 전체에서 채택을 옹호합니다.
GraphQL 기반 BFF와 마찬가지로 단일 모놀리식 GraphQL API를 유지하면 조직의 GraphQL 중심 작업을 효과적으로 통합할 수 있는 단계를 설정하는 데 도움이 될 수 있습니다.
Graph 복수 중첩
엔터프라이즈 팀은 자체 서비스별 GraphQL API를 함께 독립적으로 개발할 수도 있습니다. 이 접근 방식을 통해 팀은 유형 또는 사용 사례를 기반으로 각 서비스 API를 설명할 수 있지만 데이터의 상호 연결된 특성으로 인해 그래프 간에 겹치는 경우가 많습니다.
Graph 통합이 이러한 문제들을 어떻게 해결해주는지?
그래프를 통합하는 것은 이러한 구조적 함정을 넘어 일관성을 유지하고 기업에서 GraphQL의 잠재력을 최대한 실현하기 위한 핵심입니다.
기본 수준에서 그래프 통합으로 이동하려면 조직에 각 팀에서 만들고 관리하는 여러 그래프 대신 하나의 통합 그래프가 있어야 합니다. 그러나 해당 공통 그래프의 구현은 여러 팀에 걸쳐 통합되어야 합니다. 이것이 Principled GraphQL에 설명된 처음 두 가지 “무결성 원칙”입니다.
특히 이러한 종류의 통합 그래프로 이동하면 기업 전체의 팀이 다음을 수행할 수 있습니다.
- GraphQL API를 효과적으로 확장합니다. 균일한 관행을 구현하면 회사에서 GraphQL의 이점을 대규모로 실현할 수 있습니다. 예를 들어 팀은 그래프에 기여하기 위해 따라야 하는 워크플로 및 정책을 더 잘 이해할 수 있습니다. 마찬가지로 공통 그래프에서 데이터를 사용할 때 향상된 표준화의 이점도 누릴 수 있습니다.
- 데이터에 대한 통합 보기를 얻으십시오. 귀하의 그래프는 귀하의 제품 데이터를 나타냅니다. 이 데이터에 대한 통합 보기를 통해 해당 데이터가 현재 사용되는 방식에 대한 새로운 관점을 제공하는 동시에 미래에 데이터를 창의적으로 사용할 수 있는 영감을 줄 수 있습니다. 또한 클라이언트 애플리케이션이 해당 데이터를 사용하는 방법에 대한 일관성 측정을 적용하는 데 도움이 됩니다.
- 기존 인프라를 활용합니다. GraphQL 통합을 통해 팀은 조직의 기존 인프라를 재사용하고 팀이 데이터와 상호 작용하는 중복 작업을 제거할 수 있습니다. 또한 통합을 통해 그래프에 영향을 미치고 회사 전체에서 개별적인 노력을 최대한 활용하는 각 팀에서 개발한 사례 및 도구를 폭넓게 볼 수 있습니다.
- 코드를 더 빠르게 배송합니다. 회사는 GraphQL을 채택하여 제품을 더 빠르게 구축하고 반복합니다. GraphQL이 팀 전체에서 주목을 받으면서 이러한 이점은 이러한 성장을 지원하는 데 도움이 되는 도구를 개발하는 데 소요되는 시간으로 부분적으로 상쇄될 수 있습니다. 통합은 팀이 그래프에서 데이터에 기여하거나 소비할 때 따라야 할 명확하게 정의된 일련의 관행을 제공함으로써 잃어버린 모멘텀을 되찾는 데 도움이 됩니다.
Graph 통합 예시
통합된 페더레이션 기반 GraphQL 아키텍처는 다음으로 구성됩니다.
- 각각 고유한 GraphQL 스키마를 정의하는 하위 그래프 서비스 모음
- 개별 스키마를 통합 그래프로 구성하고 그래프의 서비스에서 쿼리를 실행하는 게이트웨이
스키마 스티칭과 같은 다른 분산형 GraphQL 아키텍처와 달리 연합은 각 하위 그래프가 담당하는 그래프의 일부만 구현할 수 있도록 하는 선언적 프로그래밍 모델을 사용합니다. 이 접근 방식을 사용하면 회사에서 별도로 유지 관리되는 GraphQL 서비스 모음으로 엔터프라이즈 규모의 그래프를 나타낼 수 있습니다. 또한 연합의 스키마 구성은 스키마 스티칭에 필요한 명령형 구현별 접근 방식과 달리 GraphQL 프리미티브를 기반으로 합니다.
Apollo Server는 하위 그래프와 게이트웨이 역할을 모두 수행할 수 있는 오픈 소스 라이브러리를 제공하지만 이러한 구성 요소는 모든 언어 및 프레임워크에서 구현할 수 있습니다. 특히 Apollo Server는 두 개의 오픈 소스 확장 라이브러리를 통해 페더레이션을 지원합니다.