Кеширование¶

Предоставление Идентификаторов Оъекта позволяет клиентам строить полные кеши.

В endpoint-based API, клиенты могут использовать кэширование HTTP, чтобы легко избежать повторной выборки ресурсов, а также для определения, что ресурсы одинаковы. URL в этих API, является полностью уникальным идентификатором, который клиент может использовать для создания кэша. Однако, в GraphQL нет примитива наподобии URL, который обеспечивает этот глобальный уникальный идентификатор для данного объекта. Из этого следует, что лучшей практикой для API является отображение такого идентификатора для клиентов.

Глобальные уникальные идентификаторы¶

Один из возможных шаблон для этого — резервирование поля, такого как id, в качестве глобального, уникального идентификатора. Пример схемы, которая использует этот подход:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  starship(id: "3003") {
    id
    name
  }
  droid(id: "2001") {
    id
    name
    friends {
      id
      name
    }
  }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "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"
        }
      ]
    }
  }
}

Это мощный инструмент в руках разработчиков клиента. Таким же образом, как и URL-адреса API предоставляют глобально уникальный ключ, поле id в этой системе обеспечивает глобальный уникальный ключ.

Если бэкэнд использует что-то вроде UUID для идентификаторов, а затем этот глобальный уникальный идентификатор — это может быть очень просто! Если бэкенд еще не имеет глобально уникальный идентификатор для каждого объекта, слой GraphQL возможно, должен создать его. Часто, это столь же просто, как прибавление имени типа к ID для использования в качестве идентификатора; сервер может затем сделать этот идентификатор непрозрачным с помощью base64.

Совместимость с существующими API¶

Одним из нюансов, связанных с использованием поля id для такой цели являет то, как клиент, использующий API GraphQL,сможет работать с существующими API. Например, если наш существующий API принял type-specific ID, а наш GraphQL API использует глобально уникальные ID, то использование их обоих может быть запутанным.

В этих случаях GraphQL API может показать ID предыдущего API по в отдельном поле. Это дает нам лучшее из обоих сторон:

• Клиенты GraphQL могут продолжать полагаться на согласованный механизм получения глобально уникального ID.
• Клиенты, которые должны работать с нашим предыдущим API, также могут вытянуть previousApiId из объекта, и использовать его.

Альтернативы¶

Глобально уникальные ID доказали свою состоятельность в прошлом, но они не являются единственным вариантами (паттернами), которые могут быть использованы. Так же, это не значит, что они являются верным выбором в любой ситуации. Действительно критической функциональностью, в которой нуждается клиент, является способность выводить глобально уникальный идентификатор для их кэширования. В то время как создание ID на сервере упрощает клиент, клиент может также установить идентификатор. Наиболее часто это просто объединение типа объекта (запрошенного через __typename) с некоторыми уникальными для данного типа id.

Кроме того, в случае замены существующего API на API GraphQL, может сбить с толку то, что все поля в GraphQL остались те же, за исключением идентификатора, который изменился на глобально уникальный. Это было бы еще одна причина, почему можно было бы не использовать id в качестве глобально уникального поля.

Комментарии