다중 커스텀 엔드포인트의 활용 사례
GraphQL은 데이터를 쿼리하기 위한 단일 엔드포인트를 노출하는 것이 일반적입니다. 그러나 각 엔드포인트가 커스터마이즈된 스키마를 제공하는 여러 커스텀 엔드포인트를 노출하는 것이 더 적합한 경우도 있습니다. 이를 통해 접근하는 엔드포인트를 변경하는 것만으로 서로 다른 사용자나 애플리케이션에 다양한 동작을 제공할 수 있습니다.
GraphQL에서 여러 엔드포인트를 노출하는 것은 REST와 동일하지 않습니다. REST에서는 각 엔드포인트가 미리 정의된 리소스나 리소스 집합에 대한 접근을 제공하지만, 여러 GraphQL 엔드포인트는 각각 여전히 스키마의 전체 데이터에 대한 접근을 제공하여 필요한 것만 정확하게 가져올 수 있습니다. 이는 여전히 일반적인 GraphQL 동작이며, 서로 다른 스키마에서 데이터에 접근할 수 있다는 점이 추가된 것입니다.
이 기능은 여러 데이터 소스를 하나의 통합 그래프로 통합하는 스키마 스티칭이나 페더레이션과도 다릅니다. 여러 엔드포인트에서는 복수의 스키마를 다루게 됩니다. 각각을 독립적으로 다루는 것이 목적이며, 더 큰 스키마의 일부로서가 아닙니다.
서로 다른 스키마를 노출함으로써 여러 독립적인 그래프에 대한 접근을 제공할 수 있습니다. GraphQL 창시자인 Lee Byron은 이것이 유용한 경우에 대해 설명합니다.
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
여러 GraphQL 엔드포인트를 노출하는 것이 적합한 추가 활용 사례를 살펴보겠습니다.
관리자 엔드포인트와 공개 엔드포인트를 분리하여 노출하기
회사 내 모든 데이터에 단일 그래프를 사용하는 경우, 접근 제어 정책을 설정하여 GraphQL 스키마의 다양한 필드에 접근할 수 있는 사용자를 검증할 수 있습니다. 예를 들어, 로그인한 사용자나 특정 역할을 가진 사용자만 접근할 수 있도록 필드를 구성할 수 있습니다.
그러나 민감하거나 기밀적인 정보를 포함하는 필드가 있어서 의도하지 않은 행위자가 절대로 접근해서는 안 되는 경우, 처음부터 이러한 필드를 공개 스키마에 노출하지 않고 팀만 접근할 수 있는 비공개 스키마에만 공개하는 것이 바람직합니다. 이 전략은 소프트웨어 버그나 스키마 구성 시 부주의 등의 의도치 않은 문제로부터 비공개 데이터를 보호하고, 특정 IP의 방문자만 비공개 엔드포인트에 접근할 수 있도록 허용함으로써 보안을 한층 강화합니다.
따라서 Admin 스키마와 Public 스키마라는 두 개의 별도 스키마를 만들고, 각각 /graphql/admin（특정 IP의 방문자만 접근 가능）과 /graphql/public（모든 사람이 접근 가능）엔드포인트로 노출할 수 있습니다.
비공개 정보에 대한 접근을 더 안전하게 제한하기
이 섹션은 이전 섹션의 일반화입니다. 공개 대 관리자의 구분뿐만 아니라, 특정 사용자 집합이 다른 사용자 집합의 정보에 확실히 접근할 수 없어야 하는 모든 상황을 다룹니다.
예를 들어, 서로 다른 클라이언트를 위해 커스터마이즈된 스키마를 만들어야 하는 경우, 각 클라이언트에 커스텀 엔드포인트（/graphql/some-client, /graphql/another-client 등）를 노출할 수 있습니다. 이는 동일한 통합 스키마에 대한 접근을 허용하고 접근 제어로 검증하는 것보다 더 안전할 수 있습니다.
서로 다른 애플리케이션에 다른 동작 제공하기
동일한 데이터 소스에 접근하는 서로 다른 애플리케이션에 각기 다른 동작을 부여할 수 있습니다.
예를 들어, Reddit은 데스크톱 브라우저에서 접근할 때와 모바일 브라우저에서 접근할 때 서로 다른 응답을 반환합니다. 데스크톱 브라우저에서는 로그인 여부에 관계없이 콘텐츠를 직접 확인할 수 있습니다.
그러나 모바일에서 접근할 때는 콘텐츠에 접근하기 위해 로그인이 필요하며, 앱 사용이 권장됩니다.
이 서로 다른 동작은 Desktop 스키마와 Mobile 스키마 두 개를 만들고, 각각 /graphql/desktop과 /graphql/mobile로 노출함으로써 구현할 수 있습니다.
사이트를 다양한 언어로 생성하기
동일한 사이트를 여러 언어로 생성하고 싶다면, 영어는 /graphql/en, 프랑스어는 /graphql/fr과 같이 언어 코드를 커스텀 엔드포인트 구조의 일부로 포함할 수 있습니다. 그러면 GraphQL 서버가 이 정보를 가져와 데이터를 원하는 언어로 번역할 수 있습니다.
마지막으로, 정적 사이트 생성기에서 이러한 각 엔드포인트를 지정하여 사이트를 원하는 언어로 생성합니다.
프로덕션 릴리스 전에 업그레이드된 스키마 테스트하기
GraphQL 스키마를 업그레이드하고 일부 사용자가 미리 테스트할 수 있도록 하려면, 이 새로운 스키마를 /graphql/upcoming 엔드포인트로 노출할 수 있습니다. 더 나아가, DEV에서 스키마를 지속적으로 배포하는 /graphql/bleeding-edge 엔드포인트도 노출할 수 있습니다.
BfF 접근 방식 지원하기
Backend-for-Frontends（약칭 BfF）는 각 클라이언트가 API를 "소유"하여 자신의 요구사항에 기반한 최적 버전을 생성할 수 있도록, 서로 다른 클라이언트를 위해 다양한 API를 생성하는 접근 방식입니다.
이 모델에서 커스텀 BfF는 백엔드 서비스와 클라이언트 사이의 중간자 역할을 합니다.
이 모델은 GraphQL에서 모든 BfF를 여러 엔드포인트를 가진 단일 GraphQL 서버로 구현하고, 각 엔드포인트가 특정 BfF/클라이언트（/graphql/mobile이나 /graphql/web 등）를 담당하는 방식으로 실현할 수 있습니다.
