iWatchYouFromAfar

Был опыт работы с www.maxmind.com/en/geoip-api-web-services, правда вне контекста MODx. Но это по сути не так важно, там rest. Сделаешь сниппет или какой-нибудь модификатор с проверкой.

Будет ли совместим MS3 с текущей компонентной базой? Или MS3 сугубо для MODx 3?

Ну вы же и делаете сейчас новый фронт на Vue — соответственно на него у вас в любом случае уйдет год, не важно откуда данные приходят, с вашего сниппета или с любого другого реста.

Значит основная проблема — бекенд. У вас API для 200 таблиц написан на MODx, где у вас все таки связаны руки. Значит перенести эту логику в условную лару не составит труда. Это же просто работа с данными которые лежат где-то в БД.

Зачем ночами сидеть и пытаться запихать на фронт сайта, который сделан на MODx — Vue, я хз. Еще вам придется решать вопросы зависимости компонентов от jQuery.

Ну… Это так, мысли в слух. Я не удивлен если у тебя на сайте будет и Vue и jQuery и что-то на ванильке. Франкеншейты они такие…

Если вы работаете на фултайме и хорошо понимаете то, на чем пишите, написать собственный функционал не составит труда. А вот что касается Vue внутри MODx, ну, апплодировать ногами тоже можно, но лишь ради развлечения других людей.

Пару лет назад я думал — было бы отлично, если бы MODx и его компоненты могли поставлять хороший и удобный REST. Там и админку свою можно набросать и на фронте наконец-то уйти от фенома и сниппетов. Сейчас я понимаю что был ох как не прав, куда проще сесть и начать писать свой бекенд. Вопрос лишь в финансах и желании. Если хотя бы один фактор отсутствует, то хер знает зачем тратить кучу времени и изобретать франкенштейна… Берешь MODx и пользуешь как есть. Товары будут продаваться и без Vue.js.

Не очень понял зачем мне статья про докер на хабре. Ты не читаешь или не так читаешь то, что я пишу. Или я не так пишу. Я имел ввиду докер в контексте MODx.

Про пост — я тебя давно понял. Статью не удалю. Буду в лесу стоять на бмв на бездорожье.

Я бы вот например с большим удовольствием почитал статью по организации докера для дева (локально) и для прода (на сервере) с автоматическим деплоем с гита.

Но у меня если честно, в голове на эту тему какой-то сумбур… Помимо миграций, там еще нужно запускать скрипты автоустановки и автонастройки компонентов. Базу файлов тоже поддерживать в актуальном состоянии. Но не думаю что в контексте MODx люди часто разворачивают VPS. В основном многие сидят на шейрингах, а там это как-бы, мало актуально, наверное.

Пишу об этом, т.к. вести разработку через контейнирезацию и Git (для системы версий и деплоя на продакшн), это очень удобно. Особенно когда хорошо умеешь в девопсе.

Критика в чем? В моих постах был рассказал про Flash, MODx, Express, Nest — твои чувства я задел только этим постом про Nest? Я безумно благодарен всем кто критиковал мои решения по MODx (посмотри историю моих заметок). Всегда нормально воспринимал критику.

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

Деревянный ты какой-то.

Люди сюда зайдут и узнают про MODX (как ты выше писал 👹)!

Про это написал не я.

Давай я тебе и здесь отвечу. Затем, что две мои прошлые статьи набрали больше лайков, чем любая из статей в готовых решениях по MODx за 2022 год. Люди писали комментарии, пару человек в телеге просили продолжение. Я видел интерес людей и никто мне не писал «зачем нам это»?

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

Думаю просто опечатка. Человек имел ввиду Nest.

Отличный вопрос. Это то, что я собираюсь изучить, наверное уже в следующем году, в силу ограниченного времени.

Переиспользование:
В Nest.js CLI есть Libraries. Это переиспользование модулей, что-то вроде того, как переиспользуются библиотеки на Vue или React из проекта в проект. Конечно, если вы пишите большое кол-во сайтов, стоит разбивать приложение на модули, а эти модули уже подключать к тому или иному приложению.

Это то, чем мне не нравился MODx. Я писал об этом несколько раз — админка слишком сложная и перегруженная. Есть такие вещи как кастомизация форм, расписание сайта, журнал системы управления, различные импорты ресурсов и т.д. Все это должно быть расширениями. Примерно как есть MiniShop2 и разработчики написали огромное кол-во компонентов, которые расширяют этот eCommerce компонент.

В Nest.js вы как раз можете дробить модули на npm пакеты и переиспользовать их в проектах, примерно как компоненты из магазина Modstore.

CMS:
CMS я уже можно сказать написал, во всяком случае пилотную версию, одного из своих клиентов на нее перевел. Но это не eCommerce, а обычный информационный сайт. Как я уже написал в статье, в планах, в следующем году реализовать большую систему для управления контентом сайта (как статьями, так и товарами). Но это будет мой внутренний продукт, выкладывать его в публичный доступ не буду.

Да эти события коснулись всех. Кого-то раньше, кого-то позже. Просто я убежден, что разработчики должны держать свою голову холодной. Принципиальный уход никому не пойдет на пользу. Это сообщество делали граждане из многих стран — Беларусь, РФ, Украина, Казахстан, Латвия, Молдавия и т.д. Если сейчас начать показывать свою позицию, это лишь усугубит ситуацию и поставит под вопрос дальнейшее существование крупнейшего сообщества по MODx.

P.S.
Я если что, не про бытовые проблемы говорю. Конечно когда денег нет и жить негде, тут уже не до MODx.

Я уверен что это пройдет. Народ вернется к обыденной жизни и к сообществу. Во всяком случае посещаемость проекта (судя по открытым данным из метрики) не упала за год.

Просто надо так же понимать, что те кто раньше писал статьи, тоже уходят в другой стек.

По аудитории понятно.

Я так понял тут сменились владельцы проекта. На самом деле всю архитектуру сотрудников в своей системе я делал вокруг пользователей из MODx. Как референс лучше чем MODx опенсурс проектов просто нет, тот же OctoberCMS, пару месяцев назад рассматривал его админку, не очень удобная и понятная конечно, имхо.

Мой посыл статей статей связан с моим уходом от MODx, и опытом, которым я делюсь в этих статьях. Во второй части я почти ничего про MODx не говорю, так что уже там можно было этот вопрос задать.

Но намек мне понятен, в городе новый шериф… ) На самом деле, думаю что все таки эта статья будет последней. Следующие буду писать на своем сайте, уже более предметные с технической стороны, без воды и историй из жизни. Так что, оставлю эти статьи на откуп новому шерифу, захочет — удалит. Хотелось закончить начатое, плюс обещал некоторым людям и со своей стороны я это сделал.

Я кстати именно так и решил попробовать Nuxt.js. ) После одной из статей Васи, полез и начал ковырять его (не Васю) пальцем.

А я искренне не понимаю почему этот вопрос задается мне на 3-ей серии статей. Аудитория прекрасно понимала статьи Василия Наумкина, Николая Ланца и многих других разработчиков, которые писали на куда более сложные темы и не всегда именно про MODx.

А что случилось с аудиторией? Переехали на другой ресурс?

1 — Nodejs фактически и есть веб-сервер, который запускается на сервере и обрабатывает JS в код нижнего уровня. Запустив такой веб-сервер, ты можешь ему передавать файлы с кодом и он (веб-сервер), их выполнит.

2 — Nodejs может исполнять код как только будет установлен в систему / на сервер. У него из коробки идет свой веб-сервер, если ты не хочешь использовать фреймворки на подобии Express. Такой веб сервер поднимается буквально в 5 строчек кода. Пример — github.com/LeCoupa/awesome-cheatsheets/blob/master/backend/node.js#L11.

3 — Я не слишком глубого знаком с работой PHP, но в рамках ноды — ты запускаешь веб-сервер, который слушает некоторый порт и этот порт проксируется через Nginx на нужный (например 80). Отбросив внутренний веб-сервер Nodejs, ты останешься без веб-сервера.

Да почти в каждом платном и даже бесплатном, более менее нормальном уроке рассматривается деплой на продакшн.

Я еще не использовал Nuxt 3 и не могу точно сказать про Nitro. Это не замена серверу Nginx, это замена серверу в среде Node.js.