GraphQLGraphQL객체 식별자를 제공하면 클라이언트가 풍부한 캐시를 구축할 수 있습니다.
엔드포인트 기반 API에서 클라이언트는 HTTP 캐싱을 사용하여 리소스 재요청을 쉽게 피하고 두 리소스가 동일한지 쉽게 식별할 수 있습니다. 이 API들의 URL이 클라이언트가 캐시를 구성하는데 사용할 수 있는 전역 고유 식별자 입니다. GraphQL에서는 주어진 객체에 대해 전역적으로 고유한 식별자를 제공하는 URL과 같은 원시값이 없습니다. 그러므로 클라이언트가 API를 사용할 수 있도록 이러한 식별자를 노출하는 것이 가장 좋습니다.
한 가지 가능한 패턴은 id 와 같은 필드를 전역적으로 고유한 식별자로 사용하는 것입니다. 이 문서 전체에 사용된 예제의 스키마는 이러한 방식을 사용합니다.
이는 클라이언트 개발자에게 넘겨줄 강력한 도구입니다. 리소스 기반 API의 URL이 전역적으로 고유한 키를 제공하는 것과 같은 방식으로 이 시스템의 id 필드는 전역적으로 고유한 키를 제공합니다.
백엔드가 식별자에 UUID와 같은 것을 사용한다면 이 전역적으로 고유한 ID를 노출하는 것은 매우 간단합니다! 백엔드에 모든 객체에 대한 전역 고유 ID가 없는 경우 GraphQL 계층에서 이를 구성해야 할 수 있습니다. 종종 ID에 타입 이름을 추가하고 이를 식별자로 사용하는 것만큼 간단합니다. 그런 다음 서버는 base64 인코딩을 통해 해당 ID를 확실하게 만들 수 있습니다.
이러한 목적을 위해 id 필드를 사용하는 것에 대한 한가지 우려는, GraphQL API를 사용하는 클라이언트가 기존 API와 어떻게 작동하는지입니다. 예를 들어, 기존 API가 타입별 ID를 허용했지만, GraphQL API가 전역 고유 ID를 사용하는 경우, 두 API를 동시에 사용하는 것은 까다로울 수 있습니다.
이러한 경우 GraphQL API는 이전 API의 ID를 별도의 필드에 표시할 수 있습니다. 이는 두 가지 장점을 제공합니다.
previousApiId 를 가져와서 사용할 수 있습니다.전역적으로 고유한 ID가 과거에는 강력한 패턴으로 입증되었지만, 사용할 수 있는 유일한 패턴이 아니며 모든 상황에 적합한 패턴도 아닙니다. 클라이언트가 필요로 하는 정말로 중요한 기능은 캐싱에 대해 전역으로 고유한 식별자를 파생시킬 수 있는 기능입니다. 서버에서 ID를 파생시키면 클라이언트가 단순화되지만, 클라이언트는 식별자도 가져야 할 수 있습니다. 이는 (__typename으로 질의하는)객체의 타입을 어떤 타입의 고유 식별자와 결합하는 것처럼 간단합니다.
또한 기존 API를 GraphQL API로 대체하는 경우, GraphQL의 모든 필드가 고유한 것으로 변경된 id 를 제외 하고 동일한 경우 혼동을 줄 수 있습니다. 이것이 하나의 전역 고유 필드로서 id 를 사용하지 않기로 결정한 또 다른 이유입니다.