Apollo-Client - длинный запрос плюс короткий запрос против одного запроса, чтобы управлять ими всеми, какой из них имеет больше смысла в памяти?

Question

Мой пользовательский запрос становится все длиннее и длиннее, и я думал о том, чтобы разделить его на два запроса: ME_QUERY, который имеет наиболее часто используемые параметры, такие как userType, userName, userID и USER_QUERY, чтобы содержать всепараметры, которые мне нужны для пользователя, но USER_QUERY понадобится только в пользовательских настройках и на странице оплаты, в то время как ME_QUERY используется почти во всех компонентах, поскольку мне нужно userType везде для ACL.

Но я не уверен, стоит ли разделять их на два запроса, поскольку они оба кэшируются в своем собственном пространстве в памяти, поэтому их разделение означает два места в памяти, в то время какдлинный запрос будет длинным, но зарезервирует только одно место в памяти, и его обновление после мутаций также будет проще.

Так что вопрос в том, нужен ли мне тоже ME_QUERY или USER_QUERY, который уже был запущен один раз после того, как пользователь вошел в систему, будет достаточно?

Ниже приведены два запроса:

export const USER_QUERY = gql`
    query {
        user {
            uid
            avatar
            isAdmin
            projectCount
            sessions
            providers
            payments // is a long object itself
            coupon
            credits
            email
            userName
            userType
            createdAt
            hasPassword
            companyName
            vatNumber
            addressLine1
            addressLine2
            country
            companySize
        }
    }
`;

export const ME_QUERY = gql`
    query {
        user {
            uid
            avatar
            isAdmin
            email
            userName
            userType
            createdAt
        }
    }
`;

Answer 1

Краткий ответ: Конечно, есть преимущество в разделении запросов, но оно заключается в улучшении работы ваших пользователей и может быть достигнуто только с правильно настроенным InMemoryCache.

Результаты запросов в Apollo нормализованы:

InMemoryCache нормализует ваши данные перед сохранением их в хранилище, разбивая результат на отдельные объекты, создавая уникальный идентификатор для каждого объекта и сохраняя эти объекты в плоской структуре данных.По умолчанию InMemoryCache будет пытаться использовать часто встречающиеся первичные ключи id и _id для уникального идентификатора, если они существуют вместе с __typename в объекте.

Если вы не видите такое поведение с вашимпользовательский запрос, вероятно, потому что ваше поле идентификатора называется uid, а не id или _id.Вам необходимо реализовать пользовательскую функцию dataIdFromObject , как описано в документации :

import { InMemoryCache, defaultDataIdFromObject } from 'apollo-cache-inmemory'

const cache = new InMemoryCache({
  dataIdFromObject: object => {
    switch (object.__typename) {
      // or whatever your user type is called
      case 'User': return `${object.__typename}:${object.uid}`
      // other types here that don't have an id or _id 
      default: return defaultDataIdFromObject(object)
    }
  }
})

Правильно настроенный кэш означает две вещи в контексте вашего вопроса:

• Запросы, извлекающие объект с тем же ключом кеша, объединят их результаты.
• Мутации, которые возвращают объект, соответствующий существующему ключу кеша, автоматически обновят этот объект.

Это означает, что вы можете разделить ваш запрос user и запросить минимальное количество полей для первоначальной загрузки вашей страницы и отложить запрос остальных полей, пока пользователь не перейдет на страницу, где эти поля необходимы.Вы можете даже использовать предварительную выборку , чтобы получить второй запрос раньше времени.

Кроме того, если у вас есть мутация, которая обновляет пользователя, если мутация возвращает объект, имеющий совпадающийключ кеша (т.е. в данном случае он включает guid), он автоматически обновит кеш для этого объекта.В этих случаях нет необходимости повторно запрашивать или обновлять хранилище вручную - Apollo все это обработает за вас.

Примечание: списки объектов в кеше не затрагиваются вышеизложенным.Если в результате мутации что-то должно быть добавлено или удалено из списка, Apollo не сможет определить, какие списки были затронуты.В этих случаях вы обновите кеш самостоятельно .

Разделение запросов может ускорить работу вашего приложения и повысить удобство работы пользователей, но не должно влиять на объем памяти или сложность.обновления кеша после мутации из-за того, как работает кеширование в Apollo.