KN
ну вообще да, тут возможно я понимаю к чему ты ведёшь
Size: a a a
2019 November 22
KN
в кверях я обычно проектирую исходя из категория -> объект -> его связи
KN
users {
find(id: 42) {
id friends { ... }
}
}KN
а в мутациях:
категория -> действия -> операции
категория -> действия -> операции
KN
users {
update (id: 42) {
addFriend(payload: { ... })
}
}DT
тээк, а почему не
?
user(id: 42) {
id
friends { ... }
}?
KN
тээк, а почему не
?
user(id: 42) {
id
friends { ... }
}?
?
DT
минус один уровень вложенности
KN
Потому что
users - это операции над категорямиKN
можно например забанить 10 человек
KN
users {
ban(id: [1, 2, 3, 4, ...])
}DT
да, но в друзья ты можешь добавить только к себе, верно?
KN
ну и в квери так же
KN
да, но в друзья ты можешь добавить только к себе, верно?
зависит от задачи ресурса, где всё проектируется
KN
но через категории получается просто гибче и понятнее на любой сложности
DT
а есть какое-то корневое поле current_user, где доступ к данным ТОЛЬКО текущего пользователя? (не для админки, а для пользователей)
KN
users { current { ... } } не?KN
но у меня это в auth вообще
KN
auth {
withToken (...) {
user { ... }
}
}DT
возможно тебе было бы удобнее сделать два эндпоинта и две схемы для админки и для неадминки (при этом пошарить типы, а мутации не шарить)