GraphQL Caching
개체 식별자를 제공하면 클라이언트가 풍부한 캐시를 구축할 수 있습니다.1)
엔드포인트 기반 API에서 클라이언트는 HTTP 캐싱을 사용하여 리소스를 쉽게 다시 가져오는 것을 방지하고 두 리소스가 동일한 경우를 식별할 수 있습니다. 이러한 API의 URL은 클라이언트가 캐시를 구축하는 데 활용할 수 있는 전역적으로 고유한 식별자입니다. 그러나 GraphQL에는 주어진 객체에 대해 이 전역적으로 고유한 식별자를 제공하는 URL과 유사한 프리미티브가 없습니다. 따라서 API가 클라이언트가 사용할 수 있도록 이러한 식별자를 노출하는 것이 모범 사례입니다.2)
Globally Unique IDs
이에 대한 한 가지 가능한 패턴은 id와 같은 필드를 전역 고유 식별자로 예약하는 것입니다. 이 문서 전체에서 사용되는 예제 스키마는 다음 접근 방식을 사용합니다.3)
{ starship(id:"3003") { id name } droid(id:"2001") { id name friends { id name } } }
{ "data": { "starship": { "id": "3003", "name": "Imperial shuttle" }, "droid": { "id": "2001", "name": "R2-D2", "friends": [ { "id": "1000", "name": "Luke Skywalker" }, { "id": "1002", "name": "Han Solo" }, { "id": "1003", "name": "Leia Organa" } ] } } }
이것은 클라이언트 개발자에게 전달할 수 있는 강력한 도구입니다. 리소스 기반 API의 URL이 전역적으로 고유한 키를 제공한 것과 같은 방식으로 이 시스템의 id 필드는 전역적으로 고유한 키를 제공합니다.4)
백엔드가 식별자에 대해 UUID와 같은 것을 사용하는 경우 이 전역적으로 고유한 ID를 노출하는 것은 매우 간단할 수 있습니다! 백엔드에 이미 모든 개체에 대해 전역적으로 고유한 ID가 없는 경우 GraphQL 계층에서 이를 구성해야 할 수 있습니다. 종종 유형의 이름을 ID에 추가하고 이를 식별자로 사용하는 것만큼 간단합니다. 그런 다음 서버는 base64로 인코딩하여 해당 ID를 불투명하게 만들 수 있습니다.5)
선택적으로 이 ID는 전역 개체 식별의 노드 패턴으로 작업하는 데 사용할 수 있습니다.6)
Compatibility with existing APIs
이 목적으로 id 필드를 사용할 때의 한 가지 문제는 GraphQL API를 사용하는 클라이언트가 기존 API와 작동하는 방식입니다. 예를 들어 기존 API가 유형별 ID를 허용했지만 GraphQL API가 전역적으로 고유한 ID를 사용하는 경우 두 가지를 동시에 사용하는 것이 까다로울 수 있습니다.7)
이러한 경우 GraphQL API는 이전 API의 ID를 별도의 필드에 노출할 수 있습니다. 이를 통해 두 가지 장점을 모두 누릴 수 있습니다.8)
Alternatives
글로벌 고유 ID는 과거에 강력한 패턴으로 입증되었지만 사용할 수 있는 유일한 패턴이 아니며 모든 상황에 적합하지도 않습니다. 클라이언트가 필요로 하는 정말 중요한 기능은 캐싱에 대해 전역적으로 고유한 식별자를 파생시키는 기능입니다. 서버가 해당 ID를 파생하도록 하면 클라이언트가 단순화되지만 클라이언트도 식별자를 파생할 수 있습니다. 종종 이것은 객체의 유형(__typename
으로 쿼리됨)을 일부 유형 고유 식별자와 결합하는 것처럼 간단합니다.11)
또한 기존 API를 GraphQL API로 교체하는 경우 전역적으로 고유하게 변경된 id를 제외하고 GraphQL의 모든 필드가 동일하면 혼동될 수 있습니다. 이것이 id를 전역적으로 고유한 필드로 사용하지 않기로 선택하는 또 다른 이유입니다.12)
관련 문서
__typename
) with some type-unique identifier.