Евгений Борисов
С нами с 17 декабря 2012; Место в рейтинге пользователей: #336 часов назад
Для второго (и последующих) контекста, то есть того, который имеет имя (key), отличное от web. Где там какой домен или поддомен, разницы нет. Как надо...
Как объединить два modx? 8
9 часов назад
Понятно, изучать вкладки в migx…
Так то я пока освоил: создаем и заполняем таблицу с данными… Потом ее выводим…
Битый день гадаю: как сделать в migx-структуру с плавающими колонками.... 7
Вчера в 21:19
Сегодня узнавала в СДЭК, что при наличии договора есть самый дешевый тариф посылка склад-склад — это для юр лиц в договором. И такой же по срокам, но ...
[msCdekWidget] Альтернативный калькулятор доставки СДЭК 18
Вчера в 10:30
Вывожу файл на странице через посредника
8kbit.ru/assets/components/webdav/index.php?action=proxy&source=2&ctx=mgr&src=files/personal/nes/videos/Zoid...
[WebDAV] Медиа источник для облачных хранилищ 22
Вчера в 00:59
Будет обновление АПИ до 3 версии или нет????
[ms_CDEK2] Вывод информации в виджете на других языках 10
25 апреля 2024, 14:36
Насколько я помню, не во всех последних релизах была проблема со старой версией PHP (с 7й), а в 2.8.6 и 3.0.4 (предыдущих на текущий момент релизах из...
Вышел MODX 2.8.7 - починили превью, можно обновляться! 11
25 апреля 2024, 00:32
Демо вроде автор закрыл, а ссылка из поста на компонент вполне рабочая, или о чем речь?
Quiz или как не потерять клиента. 86
24 апреля 2024, 14:54
Давай попробуем вот так — youtu.be/BbyfFDARgZU
mmxApp - разработка новых composer дополнений 4
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
Если кому интересно, то вот реализация для artisan под laravel gist.github.com/AgelxNash/0b6faaa7978e3456f3cbd3ef06b365da
Но по теме ветки комментариев. Мы начали разговор за реальные кейсы на GraphQL. Я понимаю, что тебе тема безопасности не важна, на SEO срать и т.д. Но если твой девиз хуяк-хуяк и в прод, то есть разработчики/студии которые стараются выпускать все-таки качественный со всех сторон продукт. И именно им в первую очередь будет познавательно узнать о реальных кейсах, а не каких-то абстрактных типо агрегирования нескольких API в один.
Но даже разбирая реальные кейсы, вместо накидывая путей решений ты тыкаешь носом в свои обрывки кода, отправляешь смотреть проекты и наработки. Но при этом на конструктивную критику ни в каком направлении не принимаешь. Если бы мы обсуждали абстрактные пути решения, статьи с того же хабра, сторонние репозитории и т.п., то диалог мог быть бы абсолютно другим. Скорее всего, мы бы поговорили за подходы к реализации как там сделано и как можно по другому. Какие плюсы и минусы выбранных реализаций и т.д. Но нет, ты тешишь свое ЧСВ показывая именно свои нарабокти, но не готов их обсуждать в негативном ключе. При этом пытаешься ущипнуть меня тем, что я якобы ничего не способен реализовать. Но не задумывался ли ты о том, что
Столько лет прошло, а ты так и не осознал мысль, что если кто-то способен найти твои ошибки, то значит этот кто-то знает больше твоего. Да, это не всегда так. Иногда это говорит о невнимательности разработчика, но этот случай явно не про тебя. Уж очень часто ты диалог заканчиваешь фразой «до безопасности доберусь, когда действительно понадобится».
Но в будущем, я все-таки думаю у Railt-а хорошие перспективы, т.к. код без жесткой завязки на фреймворк. А это значит, что его можно брать за основу не только в Laravel.
В любом случае, если бы я раньше увидел этот топик, то давно бы тебе показал это youtu.be/xETUOC4M4m4
И если бы обошлось без визгов, то мы бы конструктивно поговорили на тему ограничения прав доступа в GraphQL запросах. Затронули бы тему раскрытия путей /var/www/modxclub.ru/modxclub-3.0/ и еще много чего.
— показать, что GraphQL это не серебрянная пуля. И на реальных проектах все может оказаться несколько сложнее.
— Очередной раз подчеркнуть, что разбирая тонкости какой-то технологий, мы все дальше углубляемся в лес.
Хотя, если бы мы обсуждали не абстрактную вещь в стиле «смотрите какая крутая штука есть. на ней можно делать то и се», а разбирали реализацию GraphQL хотя бы для modx_site_content + TV, то такой материал вызвал бы
— намного больше интереса в сообществе
— позволил бы углубиться в тонкости технологии с пользой для CMS и т.п.
Про Go запрос был шутки ради. Но на всякий случай оставлю это тут github.com/gopherjs/gopherjs
На мой взгляд, агрегирование нескольких API в один, это задача частного уровня. А вот права доступа более чем насущная проблема, которая будет интересна большему кругу читателей.
github.com/VadimDez/Counter-Strike-JS
и
Одно и то же разными словами.
А насчет углубления в документацию, соглашусь с комментатором из соседнего топика modx.pro/development/18727#comment-112808 тем более,
есть свое сообщество graphql.org/community/ и много мануалов в сети.
Я ничего не имею против топиков не связанных с modx на этом сайте. Но на мой взгляд, эти топки не должны выходить за рамки вольного пересказа возможностей других технологий. Иначе сайт превратиться из сообщества modx в помойку с набором несвязанных между собой технических статей. Один только топик про minecraft это верх профильности и информационной кладези. Можно я рядом создам топик про сервера для Counter Strike?
Когда 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.