Разработка на javascript или как я до этого докатился.

Внимание! Много буков. А еще MODX будет представлен не в самом лучшем виде, но я обещаю быть объективным. Тем не менее, особо чувствительным не рекомендуется к прочтению.

Данный топик — ответ на этот комментарий.

Два года назад, почти одновременно, я начал три довольно сложных проекта. Конечно же я писал их на MODX. Но в процессе я столкнулся с некоторыми сложностями, которые на мелких и средних проектах не так сильно себя проявляли, но здесь они грели голову весьма и весьма. Что это за проблемы?

1. Работа с моделью данных.
Как много здесь тех, кто умеет программно средствами MODX редактировать таблицы? Создавать новые, редактировать имеющиеся (добавлять/удалять колонки и индексы) и т.п.? Думаю не много. И не воспринимайте это как очередное издевательство с моей стороны. Статистика говорит, что тема не очень популярная modx.pro/search?query=createObjectContainer
А не популярная она, потому что слишком сложная. Вот немного объяснения. Если вы руками подправите свои мап-файлы, вы сможете внести изменения в таблицу. И можно делать это без перегенерации схемы. Вот здесь обсуждали не очень активно добавление колонки. Жаль, что в подобных топиках желающих помочь советом знатоков не так много, как ко мне заглядывает…
Если кто-то все еще не уверен, что это сложная тема, советую к прочтению.

Так к чему я это? Проект развивался, и вместе с этим приходилось вносить изменения в базу данных. Для этого конечно же приходилось править модель. И вот ты правишь модель ручками, прописываешь связи с другими объектами, думаешь как их назвать, чтобы не возникло нигде конфликтов, потом деплоишь схему… И вот тут хорошо, если это просто добавление новых сущностей. А если надо переименовать таблицы/колонки, в которых уже есть данные?
Кстати, про конфликты имен я тоже не просто так упомянул. Что делать, если ты решил создать таблицу, которая уже используется другим компонентом? Помните, как из-за подобных конфликтов Василий поубирал свои исходники? Согласитесь, неприятно.

Есть и у меня своя «история успеха», которая очень запомнилась. Вроде никто и не виноват, но все же. Кто помнит Шона МакКормика? Если кто и не знал про него, то имеет смысл заполнить этот пробел. Когда из MODX LLC неожиданно возникло SiphonLabs, Шон ушел из MODX. Я до сих пор сожалею об этом и считаю, что именно из-за этого мы так долго ждем (или уже не ждем) MODX3. Ведь всем известный Джейсон Ковард — ярковыроженный бэкенд-разработчик. А вот ту часть админки, которую все видят, заходя в manager/ — это творение Шона. И хотя в последние несколько лет ее пытаются как-то переоформить, сделать типа лучше, на самом деле там ничего толком не меняется, потому что сама JS-логика, написанная им, до сих пор юзается как есть, и по большей части не трогается годами


Ну поменяли цвета и иконки, а что толку? се то же самое, только целлофане. Обидно на самом деле. За эти годы он много что мог полезного сделать для развития MODX, но… Замену так и не нашли.
Сорри, это небольшое лирическое отступление было, просто вспомнилось. А суть: оставил он и мне наследие :) Есть у меня один компонент, modRedirect называется. Я его особо не пиарил, так что наверняка многие не слышали, но это совсем не беда. А вот немного беда была, когда на сайте он как-то сильно забарахлил. То есть вроде есть и работает, но как-то совсем уж плохо. Пациент больше мертв, чем жив. И никаких четких признаков. Просто редиректы не срабатывают и все. Стал разбираться, и выяснилось интересное: оказывается, на сайте еще стоял Redirector от Шона. Казалось бы, стоит и стоит, верно? Компоненту несколько лет и вроде как временем проверенный. А оказалось, что хоть компонент и называется Redirector, Шон класс таблицы назвал не Redirector, а modRedirect :) Забавно, да?:) А у меня тоже modRedirect. И что получается. Вроде как везде все хорошо, но только вместо моего класса, срабатывает его. Вот и проблемка. При чем пакость в том, что не было никаких логов, технической ошибки не было, была коварная логическая ошибка.

И когда вот все это пройдешь, когда день убьешь на то, чтобы скорректировать модель, начинается следующий квест: скорректировать программный код. Запросы поменялись, параметры поменялись, короче все поменялось. А главное, смотришь такой на свой же код, который писал день/неделю/месяц назад и думаешь, а что в нем после корректировки модели можно поменять, а что нельзя. Так-то выглядит лишним, а так-то может потом где вылезет скрытой ошибкой, и ищи потом где что не так. И вот программный код растет, все это нагромождается, усложняется, и в какой-то момент начинаешь уже осознавать, что тратишь все время на корректировки имеющегося не очень хорошо работающего, вместо того, чтобы писать уже новый функционал. Просто потому что на это уже не хватает времени. Какую-то мелочь скорректировать — и понимаешь, что зацепит много всего и потом опять бесконечные корректировки…

Что же я имею на сегодня в противовес этому?
Есть вот компонент пользователя и в нем прописана структура модели этого самого пользователя (уверен, понять примерно назначение этой структуры по силу многим). Вот я себе хочу создать базу данных с таблицей на основании этой модели. Я выполняю несколько команд:

mkdir test
cd test
git clone https://github.com/prisma-cms/user-module
cd user-module/
yarn
endpoint=http://test-endpoint.modxclub.ru/user-module/test yarn deploy

И все. Вот у меня есть готовая база данных с таблицами и полями, а плюс к этому уже почти на все случаи жизни методы для работы с этими данными. youtu.be/lA0ynX0-ZsY
И готовая документация есть, какие сущности, какие поля, какие методы доступны.


Зайдите сами посмотрите test-endpoint.modxclub.ru/user-module/test и пощелкайте.

Да, это админское API, а не ограниченное, так что приведенный выше код можете самостоятельно протестировать, создав для себя свою базу и API. Просто замените test-endpoint.modxclub.ru/user-module/test на какое-нибудь свое, к примеру test-endpoint.modxclub.ru/my-user-module/my-stage

А теперь, если вы у себя все это проделали, выполните вместо endpoint=http://test-endpoint.modxclub.ru/user-module/test yarn deploy вот эту команду:
endpoint=http://test-endpoint.modxclub.ru/user-module/test yarn start
Теперь у вас запустится локально пользовательский API-сервер, по умолчанию адрес localhost:4000
Он будет сильно похож на админский, но все же отличаться. В случае с этим модулем, у вас появится не только голая модель пользователя, но и более пользовательские методы с дополнительной валидацией, такие как регистрация (signup), авторизация (signin) и получение текущего авторизованного пользователя (me).


Уже есть с чего начинать строить свою маленькую социальную сеть :) (а может и не маленькую).

А теперь выполняем все то же самое, но уже с другим модулем: github.com/prisma-cms/upload-module
Возвращаемся в тестовую папку, куда клонировали пользователей и выполняем чуть другие команды.

git clone https://github.com/prisma-cms/upload-module
cd upload-module/
yarn
endpoint=http://test-endpoint.modxclub.ru/upload-module/test yarn deploy
PORT=4001 endpoint=http://test-endpoint.modxclub.ru/upload-module/test yarn start

Я в конце добавить PORT=4001, чтобы запустить этот модуль локально на другом порту, так как сейчас порт 4000 занят модулем пользователей, и при попытке запуска будет ошибка. Error: listen EADDRINUSE :::4000
А так у меня один модуль работает на одном порту, а другой на другом. И таких сервером запустить можно много, на сколько портов хватает.

И вот у нас еще один API-сервис.

Этот, как не сложно догадаться, предназначен для загрузки файлов и доступа к ним. Админское API хранит только базовые методы для работы с базой данных, а вот в клиентском API есть методы для одиночной и мультизагрузки файлов.

Файлы вы из этого интерфейса просто так не загрузите, но ниже я покажу как это работает. Пока же условимся на том, что у нас есть один сервис под пользователей, а другой под файлы. Еще есть модули логов, почты, ресурсов, проектов-задач-таймеров и т.п., но мы не будем их сейчас все устанавливать, нам же двух для примера хватит, верно? :)

И вот сейчас самое интересное: у нас есть два отдельных сервиса. Но нам не надо два, нам надо один, и чтобы там были и пользователи, и файлы, и чтобы загрузка только для авторизованных пользователей была, и чтобы связи Пользователи-Файлы были. Короче, все хотим!

Хорошо. Хотим — значит сделаем. Мы же такие? :)

Мы сейчас находимся в модуле файлов, так давайте его и отредактируем.
1. установим user-module как зависимость yarn add @prisma-cms/user-module
2. Открываем src/modules/index.mjs и в шапке файла дописываем зависимость import UserModule from "@prisma-cms/user-module";
А в constructor в конце дописываем

this.mergeModules([
  UserModule,
]);

Выполним деплой, только в новую базу (оставим оригинал для сравнения).
endpoint=http://test-endpoint.modxclub.ru/upload-module/test2 yarn deploy

Вот теперь у нас есть и пользователи, и файлы


Единственное, нам сейчас не хватает связей Пользователи-Файлы.

Идем в папку src/modules/schema/database. Там уже есть file.graphql с описанием модели файла и мы могли бы дописать в него, но не будем так делать, а просто создадим еще один файл extended.graphql и запишем в него:

type File{
  CreatedBy: User
}

type User{
  Files: [File!]!
}

и выполним опять деплой схемы в ту же базу.
endpoint=http://test-endpoint.modxclub.ru/upload-module/test2 yarn deploy

Этот результат выполнения я процитирую здесь:

$ endpoint=http://test-endpoint.modxclub.ru/upload-module/test2 yarn deploy
✔ 
Changes:

  User (Type)
  + Created field `Files` of type `[Relation!]!`

  File (Type)
  + Created field `CreatedBy` of type `Relation`

  FileToUser (Relation)
  + Created relation between File and User


Your Prisma GraphQL database endpoint is live:

  HTTP:  http://test-endpoint.modxclub.ru/upload-module/test2
  WS:    ws://test-endpoint.modxclub.ru/upload-module/test2


⠋ Get schemaHandlerObject.flags { 'env-file': undefined }
Schema file was updated: src/schema/generated/prisma.graphql
⠋ Generating fragments for project app...src/schema/generated/api.graphql
✔ Fragments for project app written to src/schema/generated/api.fragments.js
Done in 4.39s.

После этого посмотрите изменения в схеме:


Теперь и запросы можно строить со связками:


При этом у нас не только модель, но и контроль за целостностью данных. Не даст он мне привязать к пользователю запись файла, которой не существует.


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

А вот еще фишка: я сейчас удалю схему пользователя и попробую задеплоить ее.

✖ Exited with code: 1
✔ 
Warnings:

  User
    ! You already have nodes for this model. This change will result in data loss.

If you want to ignore the warnings, please deploy with the --force flag: $ prisma deploy --force
Read more about deployment warnings here: https://bit.ly/prisma-force-flag

Ой, у меня оказывается есть данные в базе, которые будут затронуты данным изменением, поэтому прерывается. Но говорит, что если все-таки хотите удалить, выполните эту команду с флагом --force, и будет вам счастье (если бэкапы есть).


Есть в MODX что-то близкое к этому?

Ну да ладно, едем дальше. API-то у нас есть, но что делать дальше?


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

Но в нашем повествовании это еще не конец. Не зря же я вверху поставил 1. Едем дальше… Хотя вторая часть будет короче.

2. Бэк и фронт живут своей жизнью.
Вот даже не знаю, что меня больше достало, то ли модель постоянно корректировать, то ли фронт потом под изменения догонять… С каждой новой «фишкой» на странице, кошмар рос в геометрической прогрессии. Эта жучка с ее глобальной областью видимости… несвязанные друг с другом отдельные компоненты страницы, когда одно редактируешь, а другое вроде должно обновиться, но не обновляется… лишние повторные запросы на сервер… 100500 JS/CCS файлов (85% из которых уже давно не актуальна, но когда удаляешь, выясняется, что 1% оттуда все-таки использовался и именно из-за этого на всю страницу появилась большая желтая полоса)… Как вспомню… Стар я стал для всего этого дерьма…

3. На каком языке я сейчас пишу?
Заключительная причина, совсем сжатая.
Со временем начинаешь в php писать console.log(), в JS print_r()… Блин, в какой-то момент это уже начинало бесить. При чем самый треш происходит, когда какую-то часть логики с фронта нужно было перенести на бэк, а там php… Приходилось переписывать. А эти языки не только синтаксисом отличаются… Сейчас я хоть с фронта на сервер переношу, хоть наоборот во фронт. А нет, что я такое говорю?! Для меня же сейчас вообще практически нет такой разницы:) Это называется «изоморфные приложения».

На самом деле разница, конечно, бывает, особенно когда дело касается работы с файловой системой, но на практике это сейчас такой ничтожный процент работ, что можно пренебречь.

Вот, собственно, так я и докатился до этого. 8 лет плотно работал с MODX, но столкнулся с задачами, которые мне сказали «Парень, ты не осилишь нас этой мотыгой, пора хотя бы мотоблок в руки взять...». Первый год было очень больно. Не буду перечислять всего, но в ту бытность даже webpack приходилось самому конфигурировать, и graphql-схемы я вручную писал, и много еще всего интересного было. Но где-то с полгода назад я уже почувствовал, что у меня в руках уже весьма хорошие наработки, и с ними я сейчас не редко за один-два дня делаю столько, сколько до этого на MODX делал месяц, а то и не один. И вот как-то привыкаешь к хорошему и назад уже не хочется. Но каждый выбирает для себя свой путь сам, и рабочие инструменты тоже.

UPD: Забыл еще один немаловажный момент отметить: безопасность. А-я-яй! Кому-то больно стало? Да, это лето у нас жарким было. К слову, по статистике запросов вижу, что тема все еще не закрыта, до сих пор ломают MODX-сайты. Запилил свежий топик с процедурой восстановления.

Так к чему я про эту безопасность? А к тому, что в моем случае есть только одна точка активного взаимодействия с сайтом — вот это вот самое API. Другой точки просто нет. Все остальное — это на чтение только. И самая соль в том, что именно схема определяет что и в каком виде можно отправлять в API-запросах. Если сказано, что на обновление пользователя можно отправлять только fullname типа Строка, то отправить можно только строку. В последних версиях graphql вообще, если указан тип Int, а ты пытаешься отправить '10', а не 10, такое не пройдет, будет возвращена ошибка. Хотя явно '10' легко конвертируется в 10 и еще недавно graphql позволял такое пропустить, сейчас уже не позволяет.

setInterval(function(){
        for (var i = 0; i < notes.length; i++){
            var curDate = new Date().getHours() + ':' + new Date().getMinutes();
            if ( notes[i]['time'] == curDate ) {
                fs.writeFileSync("log1.txt", "OK")
            }
        }
},1000)