Схема GraphQL для края, который можно перемещать в любом направлении

У меня есть хранилище данных, и я пишу сервис / схему GraphQL, и я постоянно сталкиваюсь с проблемой концептуальной схемы ...

Допустим, у меня есть два типа узлов - пользовательский и мобильный (телефонный). Концептуально я всегда думал об отношениях как «пользователь владеет мобильным телефоном», поэтому мой пользовательский объект содержит ребро «ownnsMobile», которое разрешается в список мобильных устройств (предположим, что мои пользователи достаточно богаты, чтобы иметь более одного телефона - я ' черт возьми, я уверен, что не сейчас).

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

Или это не так уж важно, и я трагически переоцениваю это (или, что еще более трагично, не понимаю концепции?)

Дэйв.

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Что такое Apollo Client и зачем он нужен?
Что такое Apollo Client и зачем он нужен?
Apollo Client - это полнофункциональный клиент GraphQL для JavaScript-приложений, который упрощает получение, управление и обновление данных в...
0
0
48
1

Ответы 1

ownedByUser имеет больше смысла, я бы даже просто использовал ownedByownedMobiles для исходных отношений, название должно подразумевать, что это массив).

Другие вопросы по теме