Как стать автором
Обновить

Комментарии 6

Спасибо за интересную статью.

БД в вашей архитектуре берет на себя нагрузку по хранению данных и метаданных, обеспечению ссылочной целостности, рендерингу страниц, согласно метаданным.
Т.е. несколько слоев завязаны на БД.
Вопросы по БД:
  1. Как справляется базка при большой нагрузке?
  2. Реализовано ли кэширование данных для снижения нагрузки?
  3. Есть ли разграничение прав доступа при формировании запросов к БД?
  4. Есть ли защита от дурака, когда некорректный JOIN или DELETE без фильтра может «положить» среду?


Вопросы по базовым компонентам и среде:
  1. Можно-ли расширять список базовых компонентов?
  2. Можно-ли расширять список свойств у базовых компонентов?
  3. Можно-ли добавлять кастомный код обработки на клиентской строне (JavaScript)?
  4. Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?

Как справляется базка при большой нагрузке?

Я бы сказал, это одно из самых важных преимуществ платформы. Собственно у нас основные клиенты сейчас — FMCG-сети именно потому, что там большие объемы данных и сложная логика, и там скажем ORM'ы очень плохо выживают.
Реализовано ли кэширование данных для снижения нагрузки?

Кэшируется все, что связано с изменениями в сессии. Сами данные базы не кэшируются а) за это отвечают всякие shared buffers в самих СУБД, б) непонятно как ACID (в частности MVCC) поддерживать
Есть ли разграничение прав доступа при формировании запросов к БД?

Политика безопасности поддерживается на уровне платформы. Там много разных настроек, на уровне СУБД пока ничего не проверяется, если вы об этом. И если честно не совсем понятно зачем это делать.
Есть ли защита от дурака, когда некорректный JOIN или DELETE без фильтра может «положить» среду?

Напрямую к базе никто запросы не формирует. Другое дело, что никто не запретит написать invoice(InvoiceDetail id) < — NULL. Но обычно в сложных логиках существует вагон ограничений и шансов что такое действие выполнится 0. Да, теоретически запрос может повиснуть, но это обычно приводит к тому, что одно ядро проца забивается, но не более. Но для всего этого есть монитор процессов где видны все залипшие запросы и это очень быстро диагностируется.
Можно-ли расширять список базовых компонентов?

Пока нет, так как поддерживается и десктоп и веб-клиент, и непонятно даже на каком языке это делать. Но вообще в следующей версии скорее всего перейдем на схему с генерацией реакта и там можно будет любые базовые компоненты Reacta добавлять.
Можно-ли расширять список свойств у базовых компонентов?

Честно говоря не до конца понял вопрос. Но возможно в контексте предыдущего ответа это не актуально.
Можно-ли добавлять кастомный код обработки на клиентской строне (JavaScript)?

Как ни парадоксально, но наоборот можно только в десктоп-клиенте на Java (добавляется этот код все равно на сервер, где класс сериализуется, пересылается на десктоп-клиента и там выполняется). Но даже в этом случае идеологически не предполагается прямого изменения компоненты (этот код в основном используется для работы с оборудованием), предполагается, что все работает через реактивность как в React. То есть данные изменяются на сервере, клиент это чисто рендерер и генератор событий.
Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?

Да, естественно, Java. Создается Java-класс MyAction, дальше регистрируется myAction INTERNAL 'my.java.MyAction'; и этот action выполняется как будто он на lsFusion написан. Ну и через DI можно на сервере приложений инстанцировать свои объекты (например сервера какие-нибудь).
Спасибо за ответы.

>> Можно-ли расширять список свойств у базовых компонентов?
> Честно говоря не до конца понял вопрос.
> Но возможно в контексте предыдущего ответа это не актуально.
Может быть и актуально: если UI генерится через метаданные и есть логическое разделение между метаданными и базовыми элементами, которые отрабатывают переданные им настройки, то можно расширять фукнционал базовых элементов путем расширения метаданных и обработки доп. свойст на стороне базовых элементов.

>> Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?
> Да, естественно, Java.
Помимо Action, есть ли возможность «врезаться» в базову логику ядра?
Т.е. добавить кастомную логику в события ядра системы.
Например, стандартный обработчик изменения данных по сабмиту формы — событие изменение данных, перед сохранением: перед сохранением нужно сделать проверку на имя таблицы и сделать доп. инициализацию некоторых полей перед записью в таблицу.
Такое возможно?
Может быть и актуально: если UI генерится через метаданные и есть логическое разделение между метаданными и базовыми элементами, которые отрабатывают переданные им настройки, то можно расширять фукнционал базовых элементов путем расширения метаданных и обработки доп. свойст на стороне базовых элементов.

UI генерится через метаданные, но логического разделения между базовыми элементами как такового нет: а) для упрощения разработки, б) так как там как минимум 2 вида клиента один на Java, второй на JavaScript (фактически он на самом деле тоже на Java который через Gwt компайлится в JavaScript).

Это разделение возникнет при добавлении React схемы (описанной в статье), когда платформа будет генерить React-дизайн, который потом можно менять (по аналогии с отчетами). Но даже в этом случае логично с дополнительными «настройкам» работать как с данными. Например как сейчас в отчетах, надо сделать выделение цветом, просто делается свойство на форме background = IF smth(a) THEN RGB(4,3,5) ELSE RGB(12,4,5) и дальше этот background можно использовать в самом отчете (jrxml).
Помимо Action, есть ли возможность «врезаться» в базову логику ядра?
Т.е. добавить кастомную логику в события ядра системы.
Например, стандартный обработчик изменения данных по сабмиту формы — событие изменение данных, перед сохранением: перед сохранением нужно сделать проверку на имя таблицы и сделать доп. инициализацию некоторых полей перед записью в таблицу.
Такое возможно?

Есть набор стандартных событий, в том числе и ON OK:
EVENTS
    ON OK { posted(i) <- TRUE; }, // указываем, что при нажатии пользователем OK должно выполняться действия, которое выполнит действия по "проведению" данного инвойса

С добавлением своих событий, такая же ситуация как и с добавлением своих базовых компонент (в React'е все что угодно, в текущей схеме непонятно где и на каком языке). Хотя никто не мешает fork'уть репозитарий и добавить любое событие — собственно после этого mvn clean package -P assemble и можно после этого использовать свою jar вместо jar с центральных репозитариев. Но это уже конечно хардкор.

Напишите вкратце чем отличается от 1С.
и как поставлять свою конфигурацию нескольким клиентам.
и можно ли развернуть локально?
Про отличия от 1С, я полагаю вы уже нашли статью «Почему не 1С», так вот всех этих проблем в lsFusion нет (я думаю в течении месяца выйдет статья «Почему lsFusion, а не 1С», где будет в кратце рассказано как все те же проблемы решаются в lsFusion)

Поставка конфигураций в lsFusion — это не более чем копирование нового директория (или его архива в виде файла с расширением jar) в некоторый путь. То есть устанавливается платформа как служба (https://ru-documentation.lsfusion.org/pages/viewpage.action?pageId=57738078), где в зависимости от ОС / способа установки определяется путь куда надо класть исходники (файлы конфигурации).

Естественно на практике когда клиентов много это автоматизируется тем же maven'ом (для него есть стандартная задача package собрать общий архив), запуск этой задачи как правило делается в jenkins чтобы делать процесс сборки (и / или установки) автоматически или одной кнопкой в веб-интерфейсе. Также maven'ом можно собирать общий jar-архив со встроенной платформой, тогда все приложение можно поставлять как обычное java приложение. Также есть установка докером, но пока ее в основном для локальной установки используют.

Естественно все можно развернуть локально, по ссылке выше все инструкции.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий