GraphQL, Cassandra и стратегия денормализации

Будет ли хорошо работать вместе база данных, такая как Cassandra, и схема, такая как GraphQL?

Идеология Cassandra основана на идее оптимизации ваших запросов и денормализации данных. Это, похоже, не очень хорошо сочетается с идеологией GraphQL, где данные кажутся доступными на каждом уровне запроса.

Пример: предположим, что я спроектировал свою таблицу Cassandra следующим образом:

User:
    name
    address
    etc... (many properties)

Group:
    id
    name
    user_name  (denormalized user, where we generally just need the name of a user)

Но с GraphQL вряд ли можно ожидать денормализованного пользователя.

query getGroup {
   group(id: 1) {
     name
     users {
         name
     }
   }
}

Итак, пара вещей: 1.) Этот запрос GraphQL может в конечном итоге попасть в нашу базу данных Cassandra несколько раз (при условии отсутствия кеширования). Получая название группы и для каждого пользователя, мы можем даже использовать его для каждого пользователя. Но допустим, наша решимость создает несколько объектов User с помощью одного вызова cassandra.

2.) Мы не можем создать идиоматическую базу данных cassandra с учетом денормализации и graphql, не так ли? В противном случае мы должны ожидать, что определенные свойства пользователя не будут возвращены нам с запросом.

Подводя итог вопросу, какова стратегия graphql для работы с денормализованными данными? Допустимо ли опускать определенные свойства, которые, по мнению клиента, доступны? Например, клиент пытается получить доступ к адресу пользователя, но в данный момент у нас его нет, потому что наши данные денормализованы. Или следует даже не беспокоиться о денормализации и просто позволить graphQL выполнять вызовы с механизмом кеширования между db и graphql. Например, graphql сначала получает группу, а затем получает данные пользователя для идентификатора группы.


person carboncomputed    schedule 20.02.2017    source источник


Ответы (1)


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

Подумайте о таких инструментах, как загрузчик данных для кеширования при разрешении запроса.

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

person Corey    schedule 11.07.2018