Как сказать apollo-client не применять нормализацию к конкретным полям? - PullRequest
Новая
       10

Как сказать apollo-client не применять нормализацию к конкретным полям?

0 голосов
/ 22 января 2019

Моя схема GraphQL включает объекты, которые имеют большие массивы данных, которые являются уникальными для этого объекта и не будут найдены в других объектах.

Пример: 

type Position {
  time: Integer
  latitude: Float
  longitude: Float
}

type ObjectInSpaceAndTime {
  name: String
  positions(start: Int, end: Int): [Position]
}

Мое понимание нормализации в GraphQL Client заключается в том, что граф ответов будет сглаживаться, каждый экземпляр Position извлекается в кэш, для него создается уникальный ключ (с пути позиции, так что-то вроде someobject.positions.42).Это очень загружает процессор и память с тысячами значений.

Кеш будет выглядеть следующим образом: 

{
  __ObjectInSpaceAndTime.someid: {name: 'xxx'},
  __ObjectInSpaceAndTime.someid.positions.0: {time: 1221121, latitude: 0, longitude: 0},
  __ObjectInSpaceAndTime.someid.positions.1: {time: 1221122, latitude: 0, longitude: 0},
  // ...
}

Вместо этого я хотел бы сказать Apollo Client не пытаться нормализовать это и просто сохранить весь экземпляр ObjectInSpaceAndTime с его полямии, возможно, параметры, передаваемые в поля, чтобы запрос с другими атрибутами приводил к отсутствию кэша.Это значительно уменьшит работу, которую Аполлон выполняет в памяти при обработке ответа.Массив данных будет десериализован один раз из ответа и может использоваться без перебора клиента apollo-client. 

{
  __ObjectInSpaceAndTime.someid: {name: 'xxx', 
       positions: [ {time: 1221121, latitude: 0, longitude: 0}, 
                    {time: 1221122, latitude:0, longitude: 0}, 
                    /* ... */ ], 
  // ...
}

Возможно ли это с клиентом Apollo?Я не могу найти способ сделать это.

Также приветствуются предложения о том, как лучше смоделировать этот «график».

1 Ответ

0 голосов
/ 22 января 2019

Лучшее решение, которое я нашел до сих пор, - это переключиться на другой кеш, а именно apollo-cache-hermes .Гермес будет хранить только то, что они называют «сущностями», то есть объектом, возвращаемым с «id» (я упрощаю, но это поведение по умолчанию).

Я написал простой инструмент для сравнения, выбирая объект смассив из 12 тыс. «точек», связанных с ним.Одним из атрибутов точки является GPS-координата с ключами для широты и долготы.

При стандартном кэше apollo-inmemory я получаю: 

1st query (not cached)
Network time: 2358ms
Received data navDataCount=12860 Timer=3013ms  Memory=82.41MB CacheEntries=25722
2nd query (cached)
Received data navDataCount=12860 Timer=19ms  Memory=86.26MB  CacheEntries=25722

Время обработки в кэше:655ms

С apollo-hermes: 

1st query (not cached)
Network time: 2891ms
Received data navDataCount=12860 Timer=3079ms  Memory=23.36MB  CacheEntries=3
2nd query (cached)
Received data navDataCount=12860 Timer=51ms  Memory=22.37MB  CacheEntries=3

Время обработки в кеше: 188ms

(я запускал тесты несколько раз, и время обработки не сильно меняется).

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

...