Комментарии 39
У вас в проекте пользователь может загрузить картинки? Если да, то вы делаете это через GraphQL?
Интересный вопрос. Да, такая задача в перспективе есть, но еще до нее не добрались. Да и на крайний случай, никто не запретит нам это реализовать мимо GraphQL, хотя возможно это не очень красиво.
НЛО прилетело и опубликовало эту надпись здесь
В js можно получить доступ к загружаемому файлу? Даже если и да, то кажется способ не очень хороший. Всё же грузить файлы нужно мультипартом.
Возможно вы путаете с загрузкой с сервера, а тут говорется о загрузке на сервер.
Возможно вы путаете с загрузкой с сервера, а тут говорется о загрузке на сервер.
НЛО прилетело и опубликовало эту надпись здесь
Ну да, но не уверен, что там не будет ограничений в формате или размере запроса. На практике я такое не использовал, и думаю что нет сложности отправить файл стандартным способом. Думаю что доступ к загружаемому файлу из js больше необходим для какого-нибудь препроцессинга и валидации.
А какие проблемы и преимущества есть при использовании base64?
НЛО прилетело и опубликовало эту надпись здесь
Мое субъективное мнение заключается в том, что для каждой функции есть свой механизм, своя технология. Upload файлов нативно реализован через multipart, так как именно он для этого предназначен. Я думаю были причины не совать данные непосредственно в тело поста. Обход нативных механизмов всегда плох, и должен применяться только если действительно нет возможности воспользоваться стандартным способом.
Хорошая статья, для тех кто не знал с какой стороны зайти, спасибо. Мутации я так понимаю будут реализованы аналогично запросу, с сохранением данных в resolve?
Используете ли вы persisted queries?
dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5
docs.scaphold.io/tutorials/persisted-queries
dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5
docs.scaphold.io/tutorials/persisted-queries
Здравствуйте. А подскажите как вы обрабатываете исключения и выводите исключения? С глобальными в принципе понятно — есть определенный метод через который проходят все исключения — их там можно обработать, добавить всякие плюшки вроде requestId, timestamp… А как быть с мутациями где мы проверяем и сохраняем поля в базу данных или third-party сервис — обрабатывать в каждой мутации все исключения которые могут в ней возникнуть?
Да! Именно об этом я уже пишу в следующей части статьи. Тоже столкнулся с разными решениями этой проблемы, и то, которое было выбрано, считаю очень лаконичным и оптимальным. Если котортко то для этого я использовал тип Union, когда результат может быть разных типов, один из которых это кастомный ValidationErrorsType, который хранит массив текстов ошибок.
а когда примерно ждать статью по мутациям?
Надеюсь на выходных выделить время, и тогда максимум к понедельнику закончу. Но возмжоно и раньше. Как пойдет.
habrahabr.ru/post/337236 — как и обещал, правда с задержкой.
Есть 2 вопроса:
1. Возможно ли реализовать вывод деревянной структуры? к примеру список подразделений (одно приложение может входить в другое) не в виде плоского списка с идентификатором родителя, а в виде дерева. Если возможно (могу сделать рекурсивный запрос) но как будет выглядеть запрос с неизвестным уровнем вложенности?
2. Возможно ли вывести нумерованный массив? listOf позволяет выводить массивы, но индексы игнорируются. К сожалению изменить структуру и вынести индекс в атрибут не возможно.
1. Возможно ли реализовать вывод деревянной структуры? к примеру список подразделений (одно приложение может входить в другое) не в виде плоского списка с идентификатором родителя, а в виде дерева. Если возможно (могу сделать рекурсивный запрос) но как будет выглядеть запрос с неизвестным уровнем вложенности?
{
"data": {
"offices": [
"office": {
"naz" : "Офис 1",
"offices" : [
"office": {
"naz" : "Офис 1.1",
"offices" : [
...
]
},
"office": {
"naz" : "Офис 1.2"
}
]
},
"office": {
"naz" : "Офис 1"
},
...
]
}
}
}2. Возможно ли вывести нумерованный массив? listOf позволяет выводить массивы, но индексы игнорируются. К сожалению изменить структуру и вынести индекс в атрибут не возможно.
{
"data": {
"operative_control": {
"que": [
"1" : {
"R": "4",
...
},
"26" : {
"R": "6",
...
}
...
]
}
}
}
Присоединяюсь к вопросу. Я вот не смог сообразить как это сделать с MySql, чтобы не было кучи лишних запросов. С mongodb это прокатывает, но с реляционной базой данной придется попотеть.
1. Неизвестный уровень вложенности, насколько я знаю, невозможен. В этом и суть GraphQL, чтобы получать предсказуемый респонс. Но я не очень понимаю смысла возвращать неизвестный результат. Это проблема не GraphQL, а вашей архитектуры API, когда клиент заранее не знает, что получит. Возможно для каких то очень кастомных случаев. Но тогда REST вам в помощь.
Если мы говорим о рекурсии, то да, она возможна, и я с ней столкнулся на своем проекте, очень занимательно выходит с использованием GraphQL. А сам запрос выходит примерно таким:
… где поле relatedUser имеет тоже тип User как и сам user.
2. У вас изначально некорректная структура JSON. Дело в том что существует список [] и объект {}. Объект это подобие ассоциативного массива, либо же объекта в PHP. Объект содержит атрибуты ключ-значение. Список не может иметь индексов или ключей. Список это список. К конкретному элементу вы обращаетесь лишь по его порядковому номеру в списке, начиная с 0. Т.е. структура, которую вы описываете:
просто некорректна синтаксически. А задача с тем что вы говорите, решается именно выносом индекса в атрибут.
Если мы говорим о рекурсии, то да, она возможна, и я с ней столкнулся на своем проекте, очень занимательно выходит с использованием GraphQL. А сам запрос выходит примерно таким:
query {
user {
firstName
lastName
address {
zip
street
}
relatedUsers {
firstName
lastName
address {
zip
street
}
}
}
}
… где поле relatedUser имеет тоже тип User как и сам user.
2. У вас изначально некорректная структура JSON. Дело в том что существует список [] и объект {}. Объект это подобие ассоциативного массива, либо же объекта в PHP. Объект содержит атрибуты ключ-значение. Список не может иметь индексов или ключей. Список это список. К конкретному элементу вы обращаетесь лишь по его порядковому номеру в списке, начиная с 0. Т.е. структура, которую вы описываете:
...
[
"23": { ... }
]
...
просто некорректна синтаксически. А задача с тем что вы говорите, решается именно выносом индекса в атрибут.
Спасибо за ответ. По 2 вопросу я согласен с вами, но к сожалению именно такую структуру требуется создать.
По рекурсии я немного не пойму. Вы привели пример не рекурсии а двухуровнего объекта, где у пользователя могут быть подчиненные (один уровень). А рекурсия это бесконечная вложенность пока не дойдем до дна. Т.е. рекурсия это кладр: регион, район, город, населенный пункт, городской район. Притом на любом уровне может быть обрыв (например у региона обрывается на первом уровне, у города может на 2 может на 3 (если этот город в районе)).
P.S. Кладр я как пример привел, т.к. там по гуидам нужно подниматься в верх, пока не дойдем до региона
По рекурсии я немного не пойму. Вы привели пример не рекурсии а двухуровнего объекта, где у пользователя могут быть подчиненные (один уровень). А рекурсия это бесконечная вложенность пока не дойдем до дна. Т.е. рекурсия это кладр: регион, район, город, населенный пункт, городской район. Притом на любом уровне может быть обрыв (например у региона обрывается на первом уровне, у города может на 2 может на 3 (если этот город в районе)).
P.S. Кладр я как пример привел, т.к. там по гуидам нужно подниматься в верх, пока не дойдем до региона
Ваш пример «регион, район, город, населенный пункт, городской район» это не рекурсия. И дна, о котором вы говорите, у рекурсии нет. Да, я описал лишь два уровня, но GraphQL не позволить вам сделать запрос с неизвестным результатом, или неизвестной вложенностью, о чем я и говорил. А рекурсия в моем примере как раз потому, что User содержит поле типа User, но уровень вложенности вы описываете в запросе сами, т.е.:
query {
user {
name
relatedUser {
name
relatedUser {
name
relatedUser {
name
relatedUser {
...
}
}
}
}
}
}
Конечно же, такое желание вполне оправдано не только желанием сократить себе работу, но и улучшить производительность приложения.Не всегда хорошо грузить одним запросом не связанные между собой данные. Во-первых — размер. Придется пользователю подождать и смотреть на пустой экран, пока не загрузятся данные.
Можно и так. В этом и суть, что в случае с GraphQL решение стоит лишь за фронтенд разработчиком, — он может делить запросы на сколько угодно частей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем GraphQL API сервер на Yii2 с клиентом на Polymer + Apollo. Часть 1. Сервер