GraphQL для просмотра контекстно-зависимых запросов на верхнем уровне или в типе средства просмотра? - PullRequest
Новая
       21

GraphQL для просмотра контекстно-зависимых запросов на верхнем уровне или в типе средства просмотра?

0 голосов
/ 22 ноября 2018

При построении структуры запроса и типа графа в API GraphQL, куда бы вы поместили высококонтекстные запросы, которые относятся только к средству просмотра?

На верхнем уровне (запрос.friendRequests)

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

На объекте просмотра (query.viewer.friendRequests)

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

Другие примеры

  • Виджеты панели инструментов
  • Уведомления пользователя
  • Элементы действий / Элементы TODO / Списки задач
  • Сообщения
  • Счетчики и значки

Что вы, ребята, думаете по этому поводу?Какой будет хорошей рекомендацией следовать для просмотра пользовательских контекстных запросов, которые не применяются к другим пользовательским объектам в реализации API?

1 Ответ

0 голосов
/ 22 ноября 2018

Мы всегда помещаем его под определенное поле в Запрос .Сначала мы начали с запроса me, который возвращал бы пользователя.Но это оказалось не очень практичным, потому что тип пользователя стал очень большим, а также большинству полей не нужен весь объект пользователя, а только идентификатор пользователя.В вашем примере мы выполнили бы два запроса 

SELECT * FROM account WHERE id = $id
SELECT * FROM friend_request WHERE account_id = $id

Если бы мы не запросили тривиальное поле в запросе me, первый запрос был полностью потрачен.

Затем нас немного вдохновило эта тема и особенно этот ответ от Ли Байрона

Просмотрщик - это то, что мы использовали повсюду в FB, так что оно застряло у меня.Кроме того, средство просмотра не является пользователем, это сеанс аутентификации, который ссылается на пользователя.Так что есть полезное различие в терминах.

Теперь у нас есть запрос viewer, который возвращает объект Viewer.Этот объект затем имеет поле user для запроса фактического пользовательского объекта.Это также может помочь, а может и не помочь решить проблему вокруг закрытых и открытых полей вашего пользовательского объекта .

...