Как я внедрял чаты в задачи на сайте MODX-Клуба

Осторожно, реклама!

Всем привет!

Я ранее уже писал, что на сайте Клуба внедрял Чаты и Управление задачами. Чаты реализованы с помощью компонента @prisma-cms/society, а Задачи с помощью @prisma-cms/components. То есть это такие отдельные, как бы не связанные друг с другом компоненты. А вот сегодня мне захотелось сделать так, чтобы в любой отдельной задаче можно было создать свой самостоятельный чат (очень удобно, когда в проекте много задач и нельзя просто так взять и все обсудить в одном чате). И вот этот процесс сегодня по мере внедрения я описывал в статье. Получилась очень подробная и наглядная статья. Думаю, что даже при условии того, что это не на MODX написано, все равно может быть интересно почитать (просто для расширения кругозора). Если интересно, вот она: modxclub.ru/topics/vnedryaem-chaty-v-zadachi.html

Fi1osof

14 марта 2019, 10:14

1 225

-7

Комментарии: 26

Василий Наумкин

14 марта 2019, 10:19

Коль, ну это уже натурально реклама, без шуток. Тут даже не про MODX, он у тебя только в названии домена остался.

С тем же успехом можно начать ссылки про Bitrix или Laravel таскать.

Fi1osof

14 марта 2019, 10:33

Василий, судя по тому, как быстро ты ответил, ты не стал читать (что и не удивительно). Но хотя у меня там не используется MODX (если говорить о modxclub.ru), это не означает, что это не применимо к MODX. К примере, у одного из моих клиентов на сайте корзина реализована на этих технологиях. То есть сам сайт на MODX (ажна на шопкипере сделан), а во фронте используется реакт (для корзины), на сервере крутится нода, дабы дать более качественное API. Сейчас еще и поиск будет сделан с применениями этих технологий. Весь сайт переделывать затратно, а вот какие-то плюшки можно вполне так частями докидывать.
Кто-то вод сторонние сервисы подключает типа Discuss. Ты же не против подключения Disqus? Тут вот есть заметки за него: modx.pro/search?query=disqus А это 99% сторонний сервис с хранением контента на стороне и написанном не ясно на чем. Вот и здесь вполне можно думать чтобы такое полезное сделать.

Василий Наумкин

14 марта 2019, 11:00

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

Ты же пиаришь свой сайт и свои разработки, не связанные с MODX. Тебе нужны посетители, вот и пишешь здесь.

Давай ты про Prisma-CMS будешь писать, например, на Хабре? А пока от меня лично минус, дальше пусть сообщество голосует.

Fi1osof

14 марта 2019, 11:33

-2

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

Андрей Степаненко

14 марта 2019, 19:15

В виде компонента получится сделать?

Fi1osof

14 марта 2019, 19:29

Смотря что делать. Я не могу ответить да или нет, не понимая, какая задача стоит. Но скажу так: во фронте мы используем JS и часто кучу всяких сторонних JS-библиотек. То есть здесь как бы не важно MODX крутится или что (хоть статический .html). Но если говорить про клиент-серверную реализацию, то вопрос в том, куда и в каком виде запросы будут слаться и какие ответы будут прилетать. Так вот, основное ядро упомянутых технологий — GraphQL. Реализация этой технологии есть и на PHP. То есть вполне можно пилить компоненты под MODX, которые будут поддерживать GraphQL, отдавать схему, обеспечивать API и т.п. Но это не будет работать в полной мере так, как это описано у меня, потому что для того, чтобы все это работало с обработкой на сервере (включая работу с данными в БД), помимо схемы надо еще резолверы прописывать, то есть функции, обрабатывающие запросы. Чтобы было понятно о чем я, можно посмотреть на ранее опубликованные здесь топики про vue: modx.pro/search?query=vue Попытка была предпринята на замену ExtJS. Но ExtJS не работает с базой данных напрямую, он может только куда-нить слать запросы. Вот и здесь, хоть и взяли на замену ExtJS, все равно на сервере логики не прибавилось, она ограничена возможностями API MODX и установленных компонентов. Вот и с моими компонентами, их можно использовать для того, чтобы придать жизни фронту, но они не добавят логики MODX. Тем не менее, я ранее описывал, что создавал прослойку Фронт — node-server with GraphQL — (MODX || DB). Вот в таком варианте мы получали значительный прирост к гибкости API.

Андрей Степаненко

14 марта 2019, 19:35

vue js как работает прекрасно понимаю (platon.site vue + rest modx)
rest api на modx с готовой базой запросов уже есть?

Fi1osof

14 марта 2019, 19:50

Само по себе REST API в MODX очень ограниченное. Не буду объяснять почему, но если есть возражения, вполне могу аргументировать. И если вы спрашиваете про то, были ли попытки сделать на базе этого REST для готовой MODX-базы, то да, конечно были. Подробная статья: modxclub.ru/topics/izmenennaya-versiya-modxclub.ru-na-prisma-cms-poka-chto-eshhe-v-svyazke-s-modx-2817.html
Тогда еще основной бэк modxclub.ru был на MODX, но фронт уже на JS. Между ними как раз и был GraphQL-сервер на призме. Часть запросов слалось на MODX-коннекторы, а часть запросов — прямая работа с БД через ORM knex.

Андрей Степаненко

14 марта 2019, 19:38

GraphQL — он получается дает оптимизацию запросов? Ну то есть придется его изучать или там прирост скорости?

Fi1osof

14 марта 2019, 19:47

Я не могу в двух словах объяснить что такое GraphQL и для чего он нужен. Хотя можно очень коротко сказать, что это просто замена традиционному REST. Но для более полного понимания советую к прочтению: habr.com/ru/post/326986/

Андрей Степаненко

14 марта 2019, 20:05

Ключевое слово Graph:
docs.modx.com/xpdo/2.x/class-reference/xpdo/xpdo.getobjectgraph

Все ровно необходимость в описании всего этого требуется без сомнений)

query {
  posts { # это массив
    title
    body
    author { # мы может пойти глубже
      name
      avatarUrl
      profileUrl
    }
  }
}

синтаксис короче без сомнений.

на modx это аналогично составляется через sheme.

Блин ну реально можно также данные выдергивать в одной строке

$boxes = $xpdo->getCollectionGraph('Box', '{"BoxColors":{"Color":{}}}', array('Box.width' => 40));
foreach ($boxes as $box) {
    foreach ($box->getMany('BoxColors') as $boxColor) {
        echo "A box with width of 40 and a color of " . $boxColor->getOne('Color')->get('name') . " was found.\n";
    }
}

Отличие только в синтаксисе.

Глубоко лазил тоже было интересно что будет.
По сути преимущество в том что уже все загружено до того как это понадобилось всего лишь по одному слову.
Но это же напрягат весь сервер, тянутся все подряд данные. Что соответсвенно на память влияют, я тоже за то чтобы все сервера так работали)))) Но увы не все сервера так могу.

Fi1osof

14 марта 2019, 20:32

Вот так мы подошли к ключевой разнице. GraphQL — это client-first API, то есть основная его часть активная в плане составления запросов уходит на сторону клиента. Приведу поясняющий пример. Возьмем этот же запрос

query {
  posts { # это массив
    title
    body
    author { # мы может пойти глубже
      name
      avatarUrl
      profileUrl
    }
  }
}

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

query {
  posts { # это массив
    title
    body
  }
}

то и получать и отдавать сервер будет только топики. А вот авторов он не будет получать. То есть нет лишней нагрузки.

В случае же с приведенным примером на MODX Graph, серверный запрос всегда будет получать все описанные в исходном запросе данные. И всегда отдавать их все. То есть если и использовать с этим GraphQL, то в лучшем случае мы получим меньше данных в запросе (сэкономим трафик), но нагрузка от этого сильно не упадет. И второй момент: мы не сможем получить больше, то есть запрос полный описан уже, и если мы туда что-то забыли прописать на серверной части, то больше запросить и не сможем. В полноценной же реализации можно получать результаты с очень большой вложенностью.

Андрей Степаненко

14 марта 2019, 20:08

ORM knex — а вот это хорошая идея)) Тока модекс прямо сказать тут даже не каким боком не становится.

Fi1osof

14 марта 2019, 20:33

Таки да.

Андрей Степаненко

14 марта 2019, 20:11

Суть GraphQL случайно не в сборке данных в одну кучу из разных источником? Хотя все понял как работает. Ну да оптимизация бешаная)))

Fi1osof

14 марта 2019, 20:35

В том числе и это. То есть можно в одном запросе получить данные сразу из разнызх источников. Условно, мы не задумываемся о том, где и как сервер получает данные. Мы просто смотрим схему, пишем запрос в соответствии с ней и получаем ответ. Запросить что-то лишнее (отсутствующее в схеме) не получится. Это исключает распространенные случаи с классическим REST, когда на сервере логика и структура данных уже поменялась, а с фронта все еще прилетают старые запросы и мы получаем не ясно что.

Андрей Степаненко

14 марта 2019, 20:16

на apache конечно будет весеть жестко если не включить многопроцессорность

Андрей Степаненко

14 марта 2019, 20:23

Только без огромно нагрузки на сервер этот стек технологий вряд ли понадобится.

Fi1osof

14 марта 2019, 20:39

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

Андрей Степаненко

14 марта 2019, 21:58

Как сейчас можно использовать GraphQL ну к примеру с minishop? Да даже без minishop, просто полуничение ресурсов и ТВ параметров.

Андрей Степаненко

14 марта 2019, 22:08

применимость есть какая та с modx?
Просто суть в чем у меня допустим есть конфиг sphinxsearch который индексирует ресурсы. Грубо говоря необходимо установить его на сервер, отдать конфиг с настройками и установить компонент в modx, он уже будет работать.

Такое возможно сейчас с GraphQL? Просто можно и лар и python и С+ встроить в modx, но оно того стоит?

Fi1osof

15 марта 2019, 10:33

Я скажу для чего его можно использовать, на примере того же modx.pro. modx.pro — довольно старый сайт с кучей контента. И каждый раз, когда хочется что-то здесь найти, это просто ппц. У меня более 1000 комментариев. Когда я вижу чей-то вопрос, который уже задавали и на который я уже давал развернутый ответ и хочу найти этот коммент, чтобы дать ссылку, какие у меня есть для этого инструменты? Только два — 1. текстовая поисковая строка на общей странице комментов/топиков. 2. Пагинация. Не редко 15 минут потратишь и не найдешь ничего.
А вот пример запроса с использованием GraphQL: modxclub.ru/topics?filters=%7B%22CreatedBy%22%3A%7B%22username_not%22%3A%22Fi1osof%22%7D%2C%22Comments_every%22%3A%7B%22CreatedBy%22%3A%7B%22username_not%22%3A%22Fi1osof%22%7D%7D%2C%22Comments_some%22%3A%7B%7D%2C%22Blog%22%3A%7B%22name%22%3A%22%D0%BF%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0%22%7D%2C%22Tags_some%22%3A%7B%22Tag%22%3A%7B%22name_contains%22%3A%22pdo%22%7D%7D%2C%22contentText_contains%22%3A%22pdoTools%22%7D
Расшифровка: «Получить все топики, созданные не мной, в блоге Песочница, с тегом pdo, в которых есть хотя бы один комментарий и все комментарии написаны не мной». И это далеко не последний уровень вложенности запросов. Покажите на MODX хоть один проект с подобными фильтрами.

Андрей Степаненко

15 марта 2019, 10:39

А бэкенд при этом как выглядет?
Это как я понимаю фронтенд индивидуально написан?

Fi1osof

15 марта 2019, 10:46

Неправильно понимаете. Эти фильтры универсальны практически для любого источника на GraphQL. Отличие будет лишь в том, если кто-то использует не where параметр, а какой-то другой, и под это просто надо будет в фильтре указать другой параметр и все. А далее стандартно все — запрос на сервер улетает с указанными параметрами, GraphQL-сервер отдает ответ, обрабатывая запрос вообще не интересует фронт как. И не важно что там на бэке, MODX, призма, ларка или что еще. И это работает и для того варианта с modxclub.ru, когда бэк был на MODX, а призма была только миддлом.
Как это работает, подробно описано здесь: modxclub.ru/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html (ссылку копируйте и вставляйте в браузер, она тут баженно обрабатывается)

Fi1osof

15 марта 2019, 12:33