Евгений Борисов

Костылями как в Laravel?

Можно по подробнее?

Позвольте спросить, а чем вам не угодил подход, который начинал пропагандировать лет 7 назад @Fi1osof?
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.

MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.

Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.

github.com/maksatweb/compressor.io-php по крону натравите на папку. Ну или разработайте более умный алгоритм с сохранением списка уже оптимизированных картинок. У меня еще ни разу не возникало ситуации, когда CompressorIO сделал картинку битой, увеличил размер или потерял в качестве.

Если кому интересно, то вот реализация для artisan под laravel gist.github.com/AgelxNash/0b6faaa7978e3456f3cbd3ef06b365da

scotch.io/bar-talk/native-lazy-loading-launched-on-chrome-76

modx.pro/solutions/9489

3. Выходит из аккаунта.

Более чем уверен, проблема в сессии пользователя. Когда он выходит из аккаунта — удаляется все. В том числе и корзина. Если вдруг никто так и не подскажет что делать, топри добавлении товара в корзину сохраняйте список позиций в базу. Думаю уже есть готовые решения. Если нет, то можете попробовать сохранять список товаров в корзине не в сессию, а в кукисы. Если опять нет, то добавьте плагин на событие отвечающие за выход пользователя из личного кабинета и перед выходом сохраняйте список товаров в корзине.

P.S. Кстати, если получится все-таки подобрать пароль, покажи. А то пока что 9 символов подобрал, а там их 60…

gist.github.com/AgelxNash/e8bc55ea44d0798adf272269aa12ff86

Если ты несешь бред сивой кобылы считая, что пишешь прям мега позновательно. То пиши или в своем личном бложике, а потом плачься, что никто не читает. Ну или правильно реагируй на замечания. Не согласен? Ответь с аргументами, а не отговорками и перескакиванием на другие темы.

Но по теме ветки комментариев. Мы начали разговор за реальные кейсы на GraphQL. Я понимаю, что тебе тема безопасности не важна, на SEO срать и т.д. Но если твой девиз хуяк-хуяк и в прод, то есть разработчики/студии которые стараются выпускать все-таки качественный со всех сторон продукт. И именно им в первую очередь будет познавательно узнать о реальных кейсах, а не каких-то абстрактных типо агрегирования нескольких API в один.

Но даже разбирая реальные кейсы, вместо накидывая путей решений ты тыкаешь носом в свои обрывки кода, отправляешь смотреть проекты и наработки. Но при этом на конструктивную критику ни в каком направлении не принимаешь. Если бы мы обсуждали абстрактные пути решения, статьи с того же хабра, сторонние репозитории и т.п., то диалог мог быть бы абсолютно другим. Скорее всего, мы бы поговорили за подходы к реализации как там сделано и как можно по другому. Какие плюсы и минусы выбранных реализаций и т.д. Но нет, ты тешишь свое ЧСВ показывая именно свои нарабокти, но не готов их обсуждать в негативном ключе. При этом пытаешься ущипнуть меня тем, что я якобы ничего не способен реализовать. Но не задумывался ли ты о том, что

1. GitHub для меня лишь закладки на разные репозитории. Часть активности по рабочим задачам тут gitlab.com/AgelxNash в приватных репозиториях. Часть в других приватных репозиториях на серверах проектов. Но даже если ты привык лицезреть на GitHub в профилях форки, то в моем случае эти форки скорее всего потому, что я туда PR отправлял
2. Есть проекты, которые ограничены NDA. Какие-то проекты я даже не могу указывать в своем профиле как разработчик и за это в свое время была доплата, поскольку клиент параноик. Какие-то CRM системы я хоть и могу указать, но они приватные и доступны только через VPN.
3. Как я уже говорил, мне совершенно не интересно тебе что-то доказывать. Поэтому демонстрировать именно тебе проекты доведенные до стадии production у меня нет ни малейшего желания.

Это все равно не полный список

Реализованы функции далеко не для всех методов developer.mozilla.org/ru/docs/Web/HTTP/Methods, хотя они не так часто нужны.

Вообще, я даже не удивлен подобной реакцией. Сначала ты доказываешь как дохера всего знаешь, кучу новых технологий их тонкости и т.п., а все вокруг даже близко до твоего уровня не дотягивают. Но когда тебя носом тыкаешь в твои же ошибки, ты резко даешь заднюю, переключаешься на другую тему и тут же начинаешь сыпать контр-аргументами в стиле «а ты сможешь такое написать?». Да, могу. Но какое это отношение имеет к топику, ветке комментариев и т.п. — мне вообще не понятно. Что ты пытаешься доказать и главное кому?

Столько лет прошло, а ты так и не осознал мысль, что если кто-то способен найти твои ошибки, то значит этот кто-то знает больше твоего. Да, это не всегда так. Иногда это говорит о невнимательности разработчика, но этот случай явно не про тебя. Уж очень часто ты диалог заканчиваешь фразой «до безопасности доберусь, когда действительно понадобится».

С Railt могут быть проблемы при старте, т.к. документация не поспевает за кодом. Не знаю как дела обстоят с этим проектом, но выглядит очень интересно и масштабно.

Но в будущем, я все-таки думаю у Railt-а хорошие перспективы, т.к. код без жесткой завязки на фреймворк. А это значит, что его можно брать за основу не только в Laravel.

Ты действительно считаешь, что сообщество MODX должно следить за сообществом PrismaCMS? Вот если бы подобная информация была в сообществе — она бы точно получила больший охват.

В любом случае, если бы я раньше увидел этот топик, то давно бы тебе показал это youtu.be/xETUOC4M4m4
И если бы обошлось без визгов, то мы бы конструктивно поговорили на тему ограничения прав доступа в GraphQL запросах. Затронули бы тему раскрытия путей /var/www/modxclub.ru/modxclub-3.0/ и еще много чего.

Мой запрос на этот кейс преследовал 2 цели
— показать, что GraphQL это не серебрянная пуля. И на реальных проектах все может оказаться несколько сложнее.
— Очередной раз подчеркнуть, что разбирая тонкости какой-то технологий, мы все дальше углубляемся в лес.

Хотя, если бы мы обсуждали не абстрактную вещь в стиле «смотрите какая крутая штука есть. на ней можно делать то и се», а разбирали реализацию GraphQL хотя бы для modx_site_content + TV, то такой материал вызвал бы
— намного больше интереса в сообществе
— позволил бы углубиться в тонкости технологии с пользой для CMS и т.п.

В Go не силен пока

Про Go запрос был шутки ради. Но на всякий случай оставлю это тут github.com/gopherjs/gopherjs

Ну раз ты предлагаешь поговорить за технические реализации конкретных задач. И тебя не смущает, что modx.pro в первую очередь сообщество о MODX, то жду от тебя решение кейса по GraphQL с ограничением доступа к различным EndPoint и полям с данными внутри объекта.

На мой взгляд, агрегирование нескольких API в один, это задача частного уровня. А вот права доступа более чем насущная проблема, которая будет интересна большему кругу читателей.

Как же с тобой тяжело вести диалог. Фраза агрегирование нескольких API в один это разве совсем не то, что ты мне пытаешься объяснить?

Если будет на js, я бы почитал.

github.com/VadimDez/Counter-Strike-JS

API к каким-то сотороним сервисам, к коду которых нет доступа, агрегирование нескольких API в один и т.п.

и

Шлешь запрос на один сервер, а тот собирает информацию с разных серверов и возвращает все в одном ответе.

Одно и то же разными словами.

Тема еще не до конца раскрыта. Еще не рассказывалось толком ничего про ....

А насчет углубления в документацию, соглашусь с комментатором из соседнего топика modx.pro/development/18727#comment-112808 тем более,
есть свое сообщество graphql.org/community/ и много мануалов в сети.

Я ничего не имею против топиков не связанных с modx на этом сайте. Но на мой взгляд, эти топки не должны выходить за рамки вольного пересказа возможностей других технологий. Иначе сайт превратиться из сообщества modx в помойку с набором несвязанных между собой технических статей. Один только топик про minecraft это верх профильности и информационной кладези. Можно я рядом создам топик про сервера для Counter Strike?

До кучи вот еще один топик habr.com/ru/company/piter/blog/424037/

Когда PHP + JS разрабатывается одним человеком, то тут выбирай что хочешь. Но когда это разные люди или даже комманды. То GraphQL позволяет им работать независимо друг от друга.

В общем я не говорю, что REST это плохо. Я говорю о том, что когда твое API выходит за рамки 2-3 методов, то GraphQL способен упростить жизнь как при разработке, так и в поддержке.

Например, раньше я документировал API через raml.org
Мне казалось это верх удобства. Но сейчас в моем арсенале появился еще один инструмент.

З.Ы. Похоже тема топика уже более чем раскрыта. Всем спасибо за внимание:-)

Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)

В общем получается такая картина, есть язык запросов — GraphQL. А есть серверная реализация этого языка запросов. Схема в общем случае на выходе одна и не важно чем и как ты ее генерируешь.

Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека. И бизнес логика сервисного слоя будет дублироваться на двух языках. Это приведет к удорожанию стоимости всего проекта. Одно дело, когда мы берем данные в сыром виде из базы. Другое дело, когда уже добавляется какая-то логика.

Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL

Единственное, где может пригодится пример из топика — API к каким-то сотороним сервисам, к коду которых нет доступа, агрегирование нескольких API в один и т.п. Но все это задачи частного порядка.

А теперь откроем официальный сайт graphql.org/code/ и увидим серверную реализацию GraphQL на C#, Go, Java, PHP, Python, Ruby, etc… Для PHP указано аж 2 библиотеки. И одна из них webonyx/graphql-php взята за основу для Railt, который по своей сути является лишь синтаксическим сахаром для официального серверного пакета.

Так что кем бы ни был придуман GraphQL, но кидаться в омут npm пакетов и изучать шаманство в JS еще совсем не обязательно имея на руках проект PHP.

Для экономии времени смотри с 1:31:00 до 1:39:00