Процессоры в RESTful API: использовать нельзя выбросить

При планировании разработки механизма RESTful API была идея использовать стандартные процессоры. Плюсы очевидны — готовый код для CRUD с проверками прав и лексиконами. Кроме того, более простая интеграция с дополнениями. Ведь они тоже работают через процессоры. Т.е. их серверную часть переписывать не нужно. По крайней мере, не всю.

Что смущает?

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

Ответ кодируется в JSON со своим форматом. А значит его нужно раскодировать. Получается двойная работа: массив -> json -> массив.

В работе процессора заложено множество проверок с выводом ошибок — проверка прав доступа, beforeQuery(), beforeSave(),saveObject(), beforeRemove(), обработка результатов работы плагинов и т.д. И все они выводят просто сообщение без кода ошибки. Т.е. нельзя отличить ошибку «Permission denied», у которой код 403, от любой другой четырёхсотой.

Механизм процессоров, насколько я могу судить, в двойке и тройке отличаются. Т.е. данный компонент будет зависеть от версии. Хоть я и не верю в выход третьей версии, всё же я не отрицаю тот факт, что это не зависит от моей позиции. Поэтому нужно универсальное решение. Не увидел отличий.

Ну и наконец, сам код, который безумно далёк от современных стандартов. А местами и попахивает.

Это из того, что лежит на поверхности. Уверен, дальше возникнут ещё моменты. Но главный вопрос следующий — стоит ли всё-таки использовать процессоры? С одной стороны плюсы сильно сокращают количество работы. С другой — решение будет не полностью соответствовать стандартам PSR и JSON:API. Ну и полностью не соответствовать главной идее — максимально дистанцироваться от ядра, чтобы не зависеть от «хозяев» MODX.

Ох, как сейчас не хватает голосовалки. В общем, попробую сформулировать вопросы:
  1. Использовать процессоры как есть.
  2. Писать свои процессоры на основе modProcessor.
  3. Вообще не использовать механизм процессоров. Писать свой механизм по стандартам PSR с использованием шаблонов проектирования.
  4. Хозяин — барин. Делай как считаешь нужным.
Так как цель написания данного дополнения выходит за рамки ещё одного плюсика в репозитории MODX, то очень нужно услышать коллективное мнение.
Сергей Шлоков
19 сентября 2019, 09:19
modx.pro
1
692
+18
Поблагодарить автора Отправить деньги

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

Николай Савин
19 сентября 2019, 09:47
0
Ну как минимум нужен какой то механизм проверки прав и механизм вызова событий.
    Сергей Шлоков
    19 сентября 2019, 09:52
    0
    Про права я писал тут. Насчёт вызова событий нужно подумать. Это зависит от реализации.
    Наумов Алексей
    19 сентября 2019, 09:52
    0
    Думаю, что использовать стоит, по крайней мере в тех местах, где они хорошо отрабатывают.
    Просто для того, чтобы максимально быстро достичь некоего рабочего этапа.
    Если процессор позволяет выполнить действие — пусть работает.
    А если не позволяет, значит идти другим путем, писать самому это действие.
      Сергей Шлоков
      20 сентября 2019, 08:29
      0
      Думаю, это не очень правильный подход. Или одно или другое.
        Наумов Алексей
        20 сентября 2019, 09:13
        +1
        Я к тому, чтобы максимально быстро выпустить некое решение рабочее.
        Боюсь большой объем работы просто застопорит все.
        Кстати, если писать с нуля, ну по факту будут написаны аналоги процессоров, просто с другими «что смущает», которые будут подогнаны именно под это апи.
          Сергей Шлоков
          20 сентября 2019, 09:44
          0
          Боюсь большой объем работы просто застопорит все.
          Это да. Особенно когда свободного времени мало. Но я вижу причины для чего так срочно нужно выпустить решение с костылями. В крайнем, лучше сделать копи/паст по всем правилам современной разработки.
    Михаил
    19 сентября 2019, 12:52
    +6
    По мне лучше 3-й вариант. Так точно ни на что завязано не будет
      Sem
      Sem
      20 сентября 2019, 07:54
      +1
      Я тоже за 3 вариант, так как попытки обратной совместимости и вообще какой либо совместимости со старым возом ни к чему хорошему в MODX уже точно не приведут. Нужен смелый рывок вперёд — и так у компонента будет больше шансов на долгую жизнь и более широкую сферу применения.
      По поводу 1 варианта, он может хорошо выстрелить, так как можно будет очень быстро сделать рабочее решение на современных фреймворках + все имеющиеся дополнения MODX. То есть тот же miniShop2 заюзать, например, с react или vue. Вся логика бэка уже написана, посылай только rest запросы и будет счастье. Но это опять тянет за собой совместимость, от которой в данном случае, я считаю, нужно отказаться.
        Василий Наумкин
        20 сентября 2019, 09:23
        +3
        Только 3й вариант, только свои процессоры. Чтобы всё завязано было именно на них с самого начала.

        Но и они могут у себя где-то внутри вызывать процессоры MODX для работы. Это даст быстрый старт, а потом эти места можно будет улучшить и переписать.
          Сергей Шлоков
          20 сентября 2019, 09:44
          +1
          Я тоже склоняюсь за третий вариант.
            Сергей Шлоков
            20 сентября 2019, 10:20
            0
            А под своими процессорами ты имеешь ввиду свои, но наследники modProcessor, или вообще свой механизм?
            Просто ты ответил немного неопределённо —
            Только 3й вариант, только свои процессоры.
            То ли за третий, то ли за второй.

            П.С. Надо было сделать четыре комментария с каждым вариантом и за них голосовать. Эмулировать опрос. Стормозил чутка.
              Василий Наумкин
              20 сентября 2019, 10:25
              +1
              Не наследники, полностью свои процессоры, которые могут вызывать что-то из MODX, когда им это нужно.

              Голосование ни к чему, решать всё равно тебе.
            Konstantin
            20 сентября 2019, 10:48
            -2
            Ненавижу такие заголовки.
              Сергей Шлоков
              20 сентября 2019, 13:25
              +9
              Ненавижу такие комментарии.
                Это сообщение было удалено
                  Это сообщение было удалено
              Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
              17