Тема очень хороша и актуальна для текущего состояния отрасли IT, причем, если углубиться, обсасывается уже не один десяток лет. Шикарнейшая книга есть у Стива Макконнелла — «Профессиональная разработка программного обеспечения», где на протяжении всей книги сравнивается программист и инженер ПО. Инженерия говорит о зрелости отрасли, а эту зрелость обеспечивает очень и очень много факторов, и качество написания кода это хоть и важное, но только базовое качество которым должен обладать специалист-инженер.
О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.
Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.
Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
Мое субъективное мнение заключается в том, что для каждой функции есть свой механизм, своя технология. Upload файлов нативно реализован через multipart, так как именно он для этого предназначен. Я думаю были причины не совать данные непосредственно в тело поста. Обход нативных механизмов всегда плох, и должен применяться только если действительно нет возможности воспользоваться стандартным способом.
Ну да, но не уверен, что там не будет ограничений в формате или размере запроса. На практике я такое не использовал, и думаю что нет сложности отправить файл стандартным способом. Думаю что доступ к загружаемому файлу из js больше необходим для какого-нибудь препроцессинга и валидации.
Ваш пример «регион, район, город, населенный пункт, городской район» это не рекурсия. И дна, о котором вы говорите, у рекурсии нет. Да, я описал лишь два уровня, но GraphQL не позволить вам сделать запрос с неизвестным результатом, или неизвестной вложенностью, о чем я и говорил. А рекурсия в моем примере как раз потому, что User содержит поле типа User, но уровень вложенности вы описываете в запросе сами, т.е.:
query {
user {
name
relatedUser {
name
relatedUser {
name
relatedUser {
name
relatedUser {
...
}
}
}
}
}
}
Насчет кучи лишних запросов это отдельная задача. Тут нужна тонкая настройка под фреймворк. 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": { ... }
]
...
просто некорректна синтаксически. А задача с тем что вы говорите, решается именно выносом индекса в атрибут.
Да! Именно об этом я уже пишу в следующей части статьи. Тоже столкнулся с разными решениями этой проблемы, и то, которое было выбрано, считаю очень лаконичным и оптимальным. Если котортко то для этого я использовал тип Union, когда результат может быть разных типов, один из которых это кастомный ValidationErrorsType, который хранит массив текстов ошибок.
Интересный вопрос. Да, такая задача в перспективе есть, но еще до нее не добрались. Да и на крайний случай, никто не запретит нам это реализовать мимо GraphQL, хотя возможно это не очень красиво.
О зрелости стоит говорить вплоть до уровня качества инженерного образования в стране и уровня сертификации специалистов. Много ли вы знаете программистов с сертификатами? А ведь многие сервисы ее предоставляют (Zend, AWS, MySQL, т.п.). Многие если и получают их, то лишь для собственного удовлетворения. Нам до этого еще расти.
Если вы инженер высокого уровня, то вы должны делать вклад не только в свой рабочий проект, но и в отрасль вцелом. Кто пишет книги по программированию, статьи, занимается разработкой новых технологий??? Многим из нас кажется, что этим должны заниматься Facebook и Google, но на самом деле этим должен заниматься каждый инженер высокого уровня, и это, собственно, один из показателей того, что вы инженер.
Выступаете ли вы на конференциях с новыми решениями актуальных проблем, ходите ли вы на них чтобы узнать о том, с чем сталкиваются другие компании и их инженеры? Это обсуждение можно продолжать бесконечно, суть в том, что инженер это больше чем качественный программист, и нужно учиться мыслить глобальнее. Не только строчками своего кода, но и на уровне отрасли инженерии ПО вцелом.
Возможно вы путаете с загрузкой с сервера, а тут говорется о загрузке на сервер.
Если мы говорим о рекурсии, то да, она возможна, и я с ней столкнулся на своем проекте, очень занимательно выходит с использованием GraphQL. А сам запрос выходит примерно таким:
… где поле relatedUser имеет тоже тип User как и сам user.
2. У вас изначально некорректная структура JSON. Дело в том что существует список [] и объект {}. Объект это подобие ассоциативного массива, либо же объекта в PHP. Объект содержит атрибуты ключ-значение. Список не может иметь индексов или ключей. Список это список. К конкретному элементу вы обращаетесь лишь по его порядковому номеру в списке, начиная с 0. Т.е. структура, которую вы описываете:
просто некорректна синтаксически. А задача с тем что вы говорите, решается именно выносом индекса в атрибут.