Я не сношу дом. Я переношу код контроллера в другое место, убираю "extends ResourceController", и переписываю получение параметров в начале методов не из GET и POST, а из params. Постепенная легкая миграция.
Получается свой код, который уже можно переиспользовать.
Я не работал с GraphQL. С моей точки зрения он и чистый REST нужны только для каких-то особых случаев - типа public API или сайты со всей логикой на фронте (типа тех что на Firebase). Фокус группа статьи - обычные вебсайты с бэкенд API. Когда пишешь веб или мобильное приложение где бэк заточен под фронт и наоборот, то вся эта свобода в выборе параметров запроса и ответа на клиенте не нужна и даже вредна.
К тому же, с моей точки зрения, архитектурно это вещи разного уровня. GraphQL это язык, который можно использовать поверх протокола JSON-RPC. У меня был программист толковый, который без согласования реализовал такой свой язык запросов на бэк на проекте, с указанием возврата связей по foreign_id и тому подобное. Эта абстракция оказалась очень неудобной и в разработке, и в отладке и вообще не нужной. 70%++ запросов на бэк - кастомные, когда при обработке нужно проделать определенные действия, не укладывающиеся в "просто запрос данных". Какие-то запросы проще выполняются исполнением одного специфичного SQL, а не нескольких простых запросов с промежуточной обработкой данных в коде, - потому что SQL это не только select/ update, join и where на которых идеологически основываются GraphQL, REST и AR/ORM библиотеки. Я уж не говорю о безопасности - давать возможность фронту самому решать, что он может запросить, чревато.
Единственная возможная вариация, это когда какие-то данные: например, users.transactions, запрашиваются с вебсайта и, скажем, с админки. Тогда надо выдавать разный набор, который определяется источником запроса и/или ролью пользователя (admin/manager/user). Но опять же, это должен решать бэк, в целях безопасности.
Насчет "было-стало" - да, была передача данных, стала передача данных. JSON-RPC придаёт формат и строгость этой передаче. Мне эта дисциплина понравилась Тут персонально - пока не попробуешь, не поймешь нравится или нет
Управляемое кэширование на клиенте делаю сервис-воркером, на сервере - файловая система, Memcached, или что угодно - к HTTP транспорту не имеет отношения.
Принимать и отдавать файлы тоже можно массивами данных при желании, но это по усмотрению.
Но, главное, это вывод контроллеров MVC приложения из области действия HTTP контроллеров фреймворка - это уже очень много.
Да, всё это можно сделать и без JSON-RPC, но он помогает это увидеть и отвязать транспортный протокол от бизнес логики в голове разработчика.
В следующей статье покажу, как удобны batch пакеты.
Я бывал в вашей ситуации достаточно много раз. И никогда не винил в том, что я не смог сделать задачу, инструменты, которые я нанимал. Если инструмент плох - виноват не он, а тот кто его выбрал
Ты — программист. Значит что ты должен уметь заставлять компьютеры делать то, что от них требуется заказчику.
С таким подходом вы вряд ли сильно преуспеете в решении своих задач и достижении своих целей, на которые программистам зачастую, как вы правильно заметили, наплевать.
Застыл, потому что мне нравиться Vue 3 и не хочу работать одновременно и с проектами в Options Api, и в Composition API - слишком тяжело для моих мозгов. Там еще базы данных, бэкенд API, ci/cd и прочее должно уместиться
Переход на третью версию Vue/Vuetify пробовал. Потратил с день, и бросил. Если надо будет добавлять много функционала, лучше переписать. Риск менеджмент в моей голове говорит, что от Vuetify лучше отказаться добровольно
И вообще, склоняюсь, что лучше даже использовать отдельные компоненты, а не фреймворки/библиотеки для серьезных проектов
Quasar-ы хороши для быстрого кодинга, а не долгосрочного.
Язык, который определяет структуру и семантику данных, не может быть протоколом передачи данных, которому все равно, что внутри этих данных и как они устроены, покуда они в нужном (JSON) формате
Простите, читать "манюал" в котором смешивается красное и солёное не вижу смысла.
Я не сношу дом. Я переношу код контроллера в другое место, убираю "extends ResourceController", и переписываю получение параметров в начале методов не из GET и POST, а из params. Постепенная легкая миграция.
Получается свой код, который уже можно переиспользовать.
Я не работал с GraphQL. С моей точки зрения он и чистый REST нужны только для каких-то особых случаев - типа public API или сайты со всей логикой на фронте (типа тех что на Firebase). Фокус группа статьи - обычные вебсайты с бэкенд API. Когда пишешь веб или мобильное приложение где бэк заточен под фронт и наоборот, то вся эта свобода в выборе параметров запроса и ответа на клиенте не нужна и даже вредна.
К тому же, с моей точки зрения, архитектурно это вещи разного уровня. GraphQL это язык, который можно использовать поверх протокола JSON-RPC. У меня был программист толковый, который без согласования реализовал такой свой язык запросов на бэк на проекте, с указанием возврата связей по foreign_id и тому подобное. Эта абстракция оказалась очень неудобной и в разработке, и в отладке и вообще не нужной. 70%++ запросов на бэк - кастомные, когда при обработке нужно проделать определенные действия, не укладывающиеся в "просто запрос данных". Какие-то запросы проще выполняются исполнением одного специфичного SQL, а не нескольких простых запросов с промежуточной обработкой данных в коде, - потому что SQL это не только
select/update,joinиwhereна которых идеологически основываются GraphQL, REST и AR/ORM библиотеки. Я уж не говорю о безопасности - давать возможность фронту самому решать, что он может запросить, чревато.Единственная возможная вариация, это когда какие-то данные: например, users.transactions, запрашиваются с вебсайта и, скажем, с админки. Тогда надо выдавать разный набор, который определяется источником запроса и/или ролью пользователя (admin/manager/user). Но опять же, это должен решать бэк, в целях безопасности.
Вполне возможно этот заказчик попадал несколько раз на случаи, когда оптимизация ломало фатально всё уже работающее, поэтому и так осторожен теперь
А вы думаете среди юристов или экономистов не так? Любой юрист тоже может полистать учебники права и выиграть любое судебное дело, с вашей стороны?
Проблема компетентности и профессионализма есть, но описанный случай не об этом
Насчет "было-стало" - да, была передача данных, стала передача данных. JSON-RPC придаёт формат и строгость этой передаче. Мне эта дисциплина понравилась Тут персонально - пока не попробуешь, не поймешь нравится или нет
Управляемое кэширование на клиенте делаю сервис-воркером, на сервере - файловая система, Memcached, или что угодно - к HTTP транспорту не имеет отношения.
Принимать и отдавать файлы тоже можно массивами данных при желании, но это по усмотрению.
Но, главное, это вывод контроллеров MVC приложения из области действия HTTP контроллеров фреймворка - это уже очень много.
Да, всё это можно сделать и без JSON-RPC, но он помогает это увидеть и отвязать транспортный протокол от бизнес логики в голове разработчика.
В следующей статье покажу, как удобны batch пакеты.
Я бывал в вашей ситуации достаточно много раз. И никогда не винил в том, что я не смог сделать задачу, инструменты, которые я нанимал. Если инструмент плох - виноват не он, а тот кто его выбрал
Не вижу этого
Зато вижу такое:
С таким подходом вы вряд ли сильно преуспеете в решении своих задач и достижении своих целей, на которые программистам зачастую, как вы правильно заметили, наплевать.
Так это дело Васи, кем ему становится.
Ваше дело - чтобы человек, которого вы наняли, сделал проект
Или вы оговаривали, что берете его на стажировку под руководство опытных разработчиков?
Скажите, кто виноват кроме вас, что вы не проверили Васю перед принятием на Professional & Programmer?
Вот как раз админка на Vuetify 2 довольно богатая по функционалу и застыла. С ворнингами сассовскими на полминуты при билде...
Застыл, потому что мне нравиться Vue 3 и не хочу работать одновременно и с проектами в Options Api, и в Composition API - слишком тяжело для моих мозгов. Там еще базы данных, бэкенд API, ci/cd и прочее должно уместиться
Переход на третью версию Vue/Vuetify пробовал. Потратил с день, и бросил. Если надо будет добавлять много функционала, лучше переписать. Риск менеджмент в моей голове говорит, что от Vuetify лучше отказаться добровольно
И вообще, склоняюсь, что лучше даже использовать отдельные компоненты, а не фреймворки/библиотеки для серьезных проектов
Quasar-ы хороши для быстрого кодинга, а не долгосрочного.
Ну так дело не в Quasar, а в Nuxt
Quasar надо ставить не как фреймворк (CLI flavour), а как библиотеку
Так это опен сорс или проект одного человека?
Сколько кода написал именно он?
У меня тоже проект в продакшне на Vuetify 2 застыл. Похоже для развития придется переписывать на Квазаре или еще чем...
Рассматривается вопрос ускорения загрузки сайта и нет ни слова о PWA и кэшировании ресурсов service worker-ами?
GraphQL это язык
Язык, который определяет структуру и семантику данных, не может быть протоколом передачи данных, которому все равно, что внутри этих данных и как они устроены, покуда они в нужном (JSON) формате
Простите, читать "манюал" в котором смешивается красное и солёное не вижу смысла.
Там написано, что GraphQL является примером RPC протокола
В этом я запутался?
По оценкам ВОЗ
И по тому как выпускников передовых ВУЗов в 90-ые расхватывали за рубеж только по факту наличия диплома
И по тому сколько
русскихэх-СССР фамилий в топменеджменте крупных ИТ компаний на западе после 2000 годаРая не было
Но лучшие в мире доступные системы образования и здравоохранения - были. Это объективно.
Вы отстали от жизни
Сейчас самолеты всё чаще приземляются чтобы сдать буянов, а сотрудникам выдают наручники и дубинки
Это для продавца было неизвестно. А про подушевой налог было известно.
Продавец определял цену на основании своих выгод/потерь