Apollo GraphQl Хранение производных данных - PullRequest
Новая
       16

Apollo GraphQl Хранение производных данных

0 голосов
/ 24 августа 2018

Некоторый контекст : я разрабатываю приложение React JS, которое считывает географические точки из базы данных и строит графики / отображает их различными способами. Есть необработанные карты и графики, которые просто показывают данные прямо из базы данных, но есть также графики и метрики, которые включают анализ таких точек, как график уклона, площадь под графиком, гистограммы, евклидово расстояние и т. Д.

У меня настроен клиент GraphQL для передачи мне данных в мое приложение реакции с установленным Apollo-Client. Вот пример ответа GraphQL: 

{
  "data": {
    "Points": [
      {
        "pid": 13196,
        "x": 251.88491821289062,
        "y": 374.1650085449219
      },
      {
        "pid": 13197,
        "x": 257.6238708496094,
        "y": 374.17498779296875
      },
      {
        "pid": 13198,
        "x": 264.04315185546875,
        "y": 374.5350036621094
      },
      ...etc
    ]
  }
}

Это здорово! Это правильная форма, по крайней мере, для двух разных представлений данных, клиент Apollo кеширует это для меня, используя InMemoryCache, и мне еще не нужен был редукс.

Дилемма : Куча графиков, которые мне нужны, включает множество производных значений, которые используются повторно (например, я мог бы использовать значения наклона в 2 разных представлениях). Где мне хранить полученные данные?

Прямо сейчас у меня есть все вычисления, встроенные в методы React render(), но это не очень хорошая идея.

Опции:

  1. Используйте Redux для полученных данных, поместите все вычисления в редукторы и каким-то образом синхронизируйте их с тем, что находится в кэше Apollo graphql.
  2. Выполните деривацию на сервере (который я затем смогу кешировать) и отправим оба raw + по сети. Больше сетевого трафика, но меньше вычислений клиента.
  3. Продолжать вычислять полученные значения внутри render() всякий раз, когда изменяются входящие данные graphql.
  4. Может быть, то, о чем я не думал ...

1 Ответ

0 голосов
/ 26 августа 2018
  1. Redux может быть неплохим вариантом - разделение проблем / логики / данных и хорошая тестируемость.
  2. Это зависит от возможного соотношения попаданий / промахов в кэше, затрат на дополнительные ресурсы / мощность - я бы этого избежал.
  3. Визуализация не является оптимальным местом (есть другие методы жизненного цикла) для расчетов. Компонент может использовать собственное состояние (или новый getDerivedStateFromProps), но может использоваться только дочерними элементами.
  4. Вы можете использовать react context api или apollo-link-state для обмена данными / методами. Вы можете попробовать observables / mobx-подобные решения.

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

...