GraphQL: вложенные запросы против корневых запросов

Question

Я использую Apollo GraphQL на своем сервере и пытаюсь разработать API-интерфейс GraphQL.У меня один вопрос: должен ли я предпочесть вложенные запросы корневым запросам или нет.

Давайте рассмотрим оба в этом примере, где у текущего пользователя, me, много invitations.

Корневые запросы

me {
    id
    name
}

invitations {
    id
    message
}

Средство распознавания для invitations возвращает приглашения для текущего пользователя.

Вложенный запрос

me {
    id
    name
    invitations {
        id
        message
    }
}

Они должны достичь того же результата, за исключением того, что приглашения вложены в пользовательский объект me с использованием последнего подхода.Я обеспокоен тем, что если с клиентом Apollo это работает гладко для обеспечения согласованности кэша.

Каков рекомендуемый способ создания запросов GraphQL?

Answer 1

Я бы сказал, что это действительно зависит от случая.Лично я рассматриваю вложенные свойства как контекст : если потребитель API хочет получить мои уведомления , то это me { notifications { ... } }, а не notifications { ... }.Если имеет смысл иметь ключ верхнего уровня, например, есть концепция глобальных уведомлений (не зависящих от пользователя), то сделайте это.Если у каждого пользователя есть собственные уведомления (которые я предполагаю, что это правда), то me типа User должен иметь их, как и каждый User.Такое обобщение поощряет многократное мышление: панель администратора, в которой вместо me { ... } используется user(id: ...) { ... }, может использовать тот же код UI бесплатно .

Как правило,лучше подумать о том, чтобы использовать этот API, а не предоставлять его.

Answer 2

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

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