Контекстные запросы средства просмотра GraphQL на верхнем уровне или внутри типа средства просмотра?
При построении структуры запроса и типа графа в GraphQL API, где бы вы поместили высококонтекстные запросы, которые применяются только к средству просмотра?
На верхнем уровне (query.friendRequests)
Это уберет шум в объекте User и сохранит там только те запросы, которые доступны для всех пользователей. Не только просматривающий пользователь. Это добавило бы гораздо больше запросов верхнего уровня с риском того, что они станут специалистами в определенных вещах, которые на самом деле не являются идеями мышления в графике и модели данных вокруг бизнес-логики.
На сущности зрителя (query.viewer.friendRequests)
С точки зрения данных имеет смысл поместить его под сущностью средства просмотра (которая является типом пользователя). запросы на добавление в друзья всегда принадлежат родительскому объекту, который всегда является пользователем.
Другие примеры
- Виджеты приборной панели
- Уведомления пользователей
- Предметы действий / Задачи TODO / Списки задач
- Сообщения
- Счетчики и значки
Что вы думаете об этом, ребята? Что было бы хорошей практикой для просмотра пользовательских контекстных запросов, которые не применяются к другим пользовательским объектам в реализации API?
Ответы 1
Мы всегда помещали его в определенное поле в Запрос. Сначала мы начали с запроса me, который возвращал пользователя. Но это оказалось не очень практичным, потому что тип пользователя стал очень большим, а также для большинства полей нужен был не весь пользовательский объект, а только идентификатор пользователя. В вашем примере мы бы выполнили два запроса
SELECT * FROM account WHERE id = $id
SELECT * FROM friend_request WHERE account_id = $id
Если мы не будем запрашивать тривиальное поле в запросе me, первый запрос был полностью потрачен впустую.
Потом нас немного вдохновил эта ветка и особенно этот ответ от Ли Байрона.
Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.
Теперь у нас есть запрос viewer, который возвращает объект Viewer. Затем этот объект имеет поле user для запроса фактического пользовательского объекта. Это также может помочь или не поможет решить проблему проблема с частными и общедоступными полями вашего пользовательского объекта.