ИИ
это же как бы идентификатор
Size: a a a
2019 February 14
ИИ
с другой стороны, пустая строка это не null, так что всё верно
U
это из серии тех нюансов, которые глаз режут, а вроде как всё ок :)
AB
Ребята, помогите грамотно составить схему. Проект что-то вроде DigitalOcean.
1-й уровень это проект, который содержит всю информацию о продутах в нём.
2-й уровень это продукты, vds, volume, images, networks и прочее.
3-й уровень это параметры продукта, vds содержит в себе информацию о подключенных дисках, сетях, айпишниках, статистику и прочее, images например содержат список образов, а каждый образ имеет ещё кучу параметров типо размера образа, ОС образа и прочее.
Вопрос собственно в том, можно ли как-то это решить без вложенности запросов? Просто у меня вместо graphql какой-то rest получается из-за этого, и я так понимаю это бэк прэктис.
1-й уровень это проект, который содержит всю информацию о продутах в нём.
2-й уровень это продукты, vds, volume, images, networks и прочее.
3-й уровень это параметры продукта, vds содержит в себе информацию о подключенных дисках, сетях, айпишниках, статистику и прочее, images например содержат список образов, а каждый образ имеет ещё кучу параметров типо размера образа, ОС образа и прочее.
Вопрос собственно в том, можно ли как-то это решить без вложенности запросов? Просто у меня вместо graphql какой-то rest получается из-за этого, и я так понимаю это бэк прэктис.
AB
вот пример текущих мутаций. в query +- тоже самое выходит. и то здесь у меня проекты отдельно
e
для мутаций мне кажется это супер норм (?), а вот квери нужно смотреть
AB
Инстанс например можно получить в одном виде, можно все сразу, а ещё у инстанса есть группы, интерфейсы, мониторинг и ещё всякое разное
AB
И не совсем понятно, что делать, когда нужно получать один “ресурс” или несколько “ресуров”? Сейчас пробую это упаковать в resourceCollection, но мне кажется это не совсем правильно
AB
публичной апихи тоже ни одной не нашёл под подобные задачи, чтобы подсмотреть как грамотно всё реализовать
d
А почему такое отличие между типами ответов
instance/instances? А-ля упаковка с метаданными о списке отдаваемых сущностей?e
публичной апихи тоже ни одной не нашёл под подобные задачи, чтобы подсмотреть как грамотно всё реализовать
AB
А почему такое отличие между типами ответов
instance/instances? А-ля упаковка с метаданными о списке отдаваемых сущностей?ну это я по стороннему апи строю. Там instance отдаёт очень подробную инфу по инстансу с кучёв вложенных данных. А instances минимальную инфу, но сразу по всем инстансам. Я так понимаю нужно объединять?
d
Можно всегда "отдавать" (в схеме) очень подробно, но когда не надо - в запросе просто не спрашивать
AB
AB
Можно всегда "отдавать" (в схеме) очень подробно, но когда не надо - в запросе просто не спрашивать
Я так и думал, ещё не могу в голове на лету конвертировать rest в graphql
d
Чтобы не плодить типы с разным объемом данных
А по спискам есть релай - https://facebook.github.io/relay/graphql/connections.htm
А по спискам есть релай - https://facebook.github.io/relay/graphql/connections.htm
AB
Можно всегда "отдавать" (в схеме) очень подробно, но когда не надо - в запросе просто не спрашивать
а в резолверах как я понял, проверять какие аргументы пришли и в зависимости от этого делать запросы?