Pull to refresh

Comments 39

У вас в проекте пользователь может загрузить картинки? Если да, то вы делаете это через GraphQL?
Интересный вопрос. Да, такая задача в перспективе есть, но еще до нее не добрались. Да и на крайний случай, никто не запретит нам это реализовать мимо GraphQL, хотя возможно это не очень красиво.
UFO just landed and posted this here
В js можно получить доступ к загружаемому файлу? Даже если и да, то кажется способ не очень хороший. Всё же грузить файлы нужно мультипартом.

Возможно вы путаете с загрузкой с сервера, а тут говорется о загрузке на сервер.
UFO just landed and posted this here
Ну да, но не уверен, что там не будет ограничений в формате или размере запроса. На практике я такое не использовал, и думаю что нет сложности отправить файл стандартным способом. Думаю что доступ к загружаемому файлу из js больше необходим для какого-нибудь препроцессинга и валидации.
UFO just landed and posted this here
Возможно вы правы, но нужно пробовать. Да и основной concern не в ограничениях, а в корректности такого подхода.

Нормальный подход. В Stay.com так API работал для картинок.

А как решали то что в base64 размер больше?
Эм, ну у вас же должны были быть каккие-то лимиты?
UFO just landed and posted this here

50 мегабайт на фото, если верно помню. Хватало на тот момент.

А какие проблемы и преимущества есть при использовании base64?
UFO just landed and posted this here
Как проблему я вижу только то что base64 на 30% больше размер.
Мое субъективное мнение заключается в том, что для каждой функции есть свой механизм, своя технология. Upload файлов нативно реализован через multipart, так как именно он для этого предназначен. Я думаю были причины не совать данные непосредственно в тело поста. Обход нативных механизмов всегда плох, и должен применяться только если действительно нет возможности воспользоваться стандартным способом.
UFO just landed and posted this here
Хорошая статья, для тех кто не знал с какой стороны зайти, спасибо. Мутации я так понимаю будут реализованы аналогично запросу, с сохранением данных в resolve?
Спасибо. Да, так и есть, в целом реализация мутаций аналогична, за исключением некоторых моментов.
Да, читал о них, и их преимуществах, но, к сожалению, пока не дошли руки попробовать.
Здравствуйте. А подскажите как вы обрабатываете исключения и выводите исключения? С глобальными в принципе понятно — есть определенный метод через который проходят все исключения — их там можно обработать, добавить всякие плюшки вроде requestId, timestamp… А как быть с мутациями где мы проверяем и сохраняем поля в базу данных или third-party сервис — обрабатывать в каждой мутации все исключения которые могут в ней возникнуть?
Да! Именно об этом я уже пишу в следующей части статьи. Тоже столкнулся с разными решениями этой проблемы, и то, которое было выбрано, считаю очень лаконичным и оптимальным. Если котортко то для этого я использовал тип Union, когда результат может быть разных типов, один из которых это кастомный ValidationErrorsType, который хранит массив текстов ошибок.
а когда примерно ждать статью по мутациям?
Надеюсь на выходных выделить время, и тогда максимум к понедельнику закончу. Но возмжоно и раньше. Как пойдет.
Есть 2 вопроса:
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 это прокатывает, но с реляционной базой данной придется попотеть.
Насчет кучи лишних запросов это отдельная задача. Тут нужна тонкая настройка под фреймворк. Yii2 очень хорошо справляется с оптимизацией запросов, если правильно его использовать.
1. Неизвестный уровень вложенности, насколько я знаю, невозможен. В этом и суть GraphQL, чтобы получать предсказуемый респонс. Но я не очень понимаю смысла возвращать неизвестный результат. Это проблема не GraphQL, а вашей архитектуры API, когда клиент заранее не знает, что получит. Возможно для каких то очень кастомных случаев. Но тогда REST вам в помощь.
Если мы говорим о рекурсии, то да, она возможна, и я с ней столкнулся на своем проекте, очень занимательно выходит с использованием 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. Кладр я как пример привел, т.к. там по гуидам нужно подниматься в верх, пока не дойдем до региона
Ваш пример «регион, район, город, населенный пункт, городской район» это не рекурсия. И дна, о котором вы говорите, у рекурсии нет. Да, я описал лишь два уровня, но GraphQL не позволить вам сделать запрос с неизвестным результатом, или неизвестной вложенностью, о чем я и говорил. А рекурсия в моем примере как раз потому, что User содержит поле типа User, но уровень вложенности вы описываете в запросе сами, т.е.:
query {
	user {
		name
		relatedUser {
			name
			relatedUser {
				name
				relatedUser {
					name
					relatedUser {

						...

					}
				}
			}
		}
	}
}
Конечно же, такое желание вполне оправдано не только желанием сократить себе работу, но и улучшить производительность приложения.
Не всегда хорошо грузить одним запросом не связанные между собой данные. Во-первых — размер. Придется пользователю подождать и смотреть на пустой экран, пока не загрузятся данные.
Тут говорилось в контексте того, что фронтенд-разработчик желает получать лишь необходимые данные, а не всё подряд.
Да но можно получить лишь часть данных и показать их пользователю, а остальные подруэить.
Можно и так. В этом и суть, что в случае с GraphQL решение стоит лишь за фронтенд разработчиком, — он может делить запросы на сколько угодно частей.
Можно и так. В этом и суть, что в случае с GraphQL решение стоит лишь за фронтенд разработчиком, — он может делить запросы на сколько угодно частей.
Only those users with full accounts are able to leave comments. Log in, please.