Зачем нужна платформа в эпоху ИИ?
На прошлом месте работы я почти 10 лет внедрял CRM на базе платформ (сначала MS Dynamics CRM, затем Creatio/BPMSoft), на новом месте один из проектов у нас на базе Битрикс24.
Современные коммерческие платформы много чего умеют уже из коробки - не просто объектную модель накликать, собрать под нее интерфейс и даже бизнес-процессов в дизайнере нарисовать, в некоторых даже интеграции можно было настраивать. И все это без строчки кода, мышкой в UI. Разработчики платформ вложили дофига сил чтобы все это выглядело красиво и было простым в настройке. Ну, по крайней мере, казалось простым на пресейловом демо, в реальности без интегратора или своего отдела разработки клиент там максимум воронку на дашборде мог настроить.
И тут на сцену врываются сначала Cursor, а затем Claude. Теперь не нужно вкладываться в разработку деньгами и временем, каждый может стать вайбкодером всего за $20 в месяц и писать любые приложения, хоть CRM целые. Когда я впервые услышал от топ-менеджера нашей компании что он там на выходных что-то навайбкодил, я был в легком недоумении. Потом с аналогичной историей пришел второй и третий, и я понял, что этот ваш ИИ – просто новый источник дофамина, причем чем меньше ты понимаешь в программировании, тем большую дозу получаешь. Зафигачил промт – оно пожужжало несколько минут и что-то выдало; смотришь – а там вроде и то что нужно, а вроде и не совсем, и новый промт фигачишь чтобы исправить. Возможно, на какой-то итерации получишь что-то достаточно хорошее. Чем-то похоже на лудоманию.
И ведь когда спрашиваешь таких новоявленных вайбкодеров: "ну у тебя получилось сделать что хотел?" в ответ получаешь "ну я потыкался вроде похоже, а насколько оно реально правильно работает/считает я не проверял". И вот тут-то у нас первая проблема: ИИ дает иллюзию того, что разработка это просто, но это не совсем так. Правило Парето никто не отменял, оно и к вайбкодингу применимо, единственное отличие – код пишется быстрее и можно даже не особо вникать что там написано. Но учесть все нюансы работы приложения с первого раза – это из области фантастики.
Вообще вот эта вот ИИ-разработка очень напоминает мне древнюю цитату с Баша: "Мне недавно рассказали как делают корабли в бутылках. В бутылку засыпают силикатного клея, говна и трясут. Получаются разные странные штуки, иногда корабли."
Продолжение в следующем посте.
На прошлом месте работы я почти 10 лет внедрял CRM на базе платформ (сначала MS Dynamics CRM, затем Creatio/BPMSoft), на новом месте один из проектов у нас на базе Битрикс24.
Современные коммерческие платформы много чего умеют уже из коробки - не просто объектную модель накликать, собрать под нее интерфейс и даже бизнес-процессов в дизайнере нарисовать, в некоторых даже интеграции можно было настраивать. И все это без строчки кода, мышкой в UI. Разработчики платформ вложили дофига сил чтобы все это выглядело красиво и было простым в настройке. Ну, по крайней мере, казалось простым на пресейловом демо, в реальности без интегратора или своего отдела разработки клиент там максимум воронку на дашборде мог настроить.
И тут на сцену врываются сначала Cursor, а затем Claude. Теперь не нужно вкладываться в разработку деньгами и временем, каждый может стать вайбкодером всего за $20 в месяц и писать любые приложения, хоть CRM целые. Когда я впервые услышал от топ-менеджера нашей компании что он там на выходных что-то навайбкодил, я был в легком недоумении. Потом с аналогичной историей пришел второй и третий, и я понял, что этот ваш ИИ – просто новый источник дофамина, причем чем меньше ты понимаешь в программировании, тем большую дозу получаешь. Зафигачил промт – оно пожужжало несколько минут и что-то выдало; смотришь – а там вроде и то что нужно, а вроде и не совсем, и новый промт фигачишь чтобы исправить. Возможно, на какой-то итерации получишь что-то достаточно хорошее. Чем-то похоже на лудоманию.
И ведь когда спрашиваешь таких новоявленных вайбкодеров: "ну у тебя получилось сделать что хотел?" в ответ получаешь "ну я потыкался вроде похоже, а насколько оно реально правильно работает/считает я не проверял". И вот тут-то у нас первая проблема: ИИ дает иллюзию того, что разработка это просто, но это не совсем так. Правило Парето никто не отменял, оно и к вайбкодингу применимо, единственное отличие – код пишется быстрее и можно даже не особо вникать что там написано. Но учесть все нюансы работы приложения с первого раза – это из области фантастики.
Вообще вот эта вот ИИ-разработка очень напоминает мне древнюю цитату с Баша: "Мне недавно рассказали как делают корабли в бутылках. В бутылку засыпают силикатного клея, говна и трясут. Получаются разные странные штуки, иногда корабли."
Продолжение в следующем посте.
Зачем нужна платформа в эпоху ИИ. Часть 2
Вернемся к теме. Зачем же платформа, когда ИИ может написать что угодно? Ответ простой: время. Те, кто в разработке давно знают, что написание кода – это только часть процесса, состоящего из:
- сбора требований
- проектирования
- непосредственно написания кода
- тестирования и исправления багов
- раскатки доработок на среды
Допустим, мы хотим сделать что-то сложнее тетриса. Например, корпоративную CRM-систему под свои нужды. Давайте загибать пальчики:
1. Требования собирать и описывать нужно? Нужно. ИИ может помочь, но человеки (участники автоматизируемых процессов) все равно должны прочитать, понять и согласиться. За одну итерацию не получается согласовать ни у кого.
2. Проектирование – скажем так, если вы не планируете вносить изменения в однажды разработанный продукт, можно шаг пропустить. Опять же, ИИ тут может помочь, но лучше перечитать что он напроектировал.
3. Написание кода – тут ноль вопросов.
4. Тестирование – а этот этап у вайбкодеров внезапно сильно длиннее, ведь даже в условиях идеально описанных требований и результатов проектирования, ИИ все равно лажает. Тут забудет, там вольно интерпретирует, в итоге результат будет похож на правду, но не то. Исправит-то он конечно быстро, но потом же опять тестировать.
5. Раскатка на среды. О, об этом далекие от программирования люди вообще обычно не думают, но если спросить "как?" не моргнув глазом идут уточнять у ИИ. Через некоторое время обычно сдаются и приходят к идее спихнуть задачу на ИТ-отдел. Ведь вайбкодер сделал своё дело, вайбкодер может идти, а скучные вещи пусть айтишники делают.
Еще можно задавать каверзные вопросы типа "представляешь, захочешь через месяц доработку к своей системе на прод выкатить, а там уже данных дофига внести успели, как делать это будешь?". Тот, кто пропустил фазу проектирования и забыл учесть вопрос с миграциями в БД обычно выглядит в такие моменты очень озадаченным.
А теперь про платформы.
Ребята, 70% любой бизнес-системы это простые CRUD-интерфейсы с накрученной ролевой, по сути красивая обертка над базой данных. ИИ справляется с этим уже очень хорошо, но платформы не сильно отстают. Причем накликивая все это в платформе ты знаешь, что работать оно будет предсказуемо, а в случае с ИИ - проверять еще надо.
Еще 20% бизнес-системы это логика разной степени хитрости. Тут платформам нечем крыть, любой мало-мальски сложный бизнес-процесс потребует разработки, т.к. встроенных средств недостаточно.
Оставшиеся 10% обычно всякие интеграции, хоть тот же SSO для системы или отправка sms/email. В платформе просто задаешь нужные параметры и пользуешься, причем зная, что эту фичу уже оттестировали миллион раз и вероятность словить в этом месте баг крайне низка.
Если считать по баллам, получается плюс-минус одинаково. Да, у платформы есть минус в виде стоимости лицензий, но
1. Есть же полноценные opensource-платформы.
2. У платных есть киллер-фича под названием "саппорт". Если в проде у вас происходит любая НËХ вы просто заводите вендору тикет и не паритесь. Шучу, паритесь конечно если система совсем встала, просто знаете что решать проблему не вам, и это приятно.
Не знаю почему в первом пункте написал "платформы" во множественом числе, на данный момент на рынке таких ровно одна. В общем-то, канал как раз про неё.
Выводы: если вы рассматриваете вариант "навайбкодить себе бизнес-систему" значит денег купить нормальную у вас, скорее всего, нет (разве что $100 на подписку Claude Max). Я бы рекомендовал в таком случае потратить немного времени на изучение opensource-платформы и реализовать свои фантазии на ней, а там где нужно реализовать сложную логику - вот ее реализовать с ИИ.
Тогда можно получить все плюшки платформы в виде стабильности и отлаженных процессов и подружить со скоростью реализации нестандартных хотелок, которые дает ИИ.
Вернемся к теме. Зачем же платформа, когда ИИ может написать что угодно? Ответ простой: время. Те, кто в разработке давно знают, что написание кода – это только часть процесса, состоящего из:
- сбора требований
- проектирования
- непосредственно написания кода
- тестирования и исправления багов
- раскатки доработок на среды
Допустим, мы хотим сделать что-то сложнее тетриса. Например, корпоративную CRM-систему под свои нужды. Давайте загибать пальчики:
1. Требования собирать и описывать нужно? Нужно. ИИ может помочь, но человеки (участники автоматизируемых процессов) все равно должны прочитать, понять и согласиться. За одну итерацию не получается согласовать ни у кого.
2. Проектирование – скажем так, если вы не планируете вносить изменения в однажды разработанный продукт, можно шаг пропустить. Опять же, ИИ тут может помочь, но лучше перечитать что он напроектировал.
3. Написание кода – тут ноль вопросов.
4. Тестирование – а этот этап у вайбкодеров внезапно сильно длиннее, ведь даже в условиях идеально описанных требований и результатов проектирования, ИИ все равно лажает. Тут забудет, там вольно интерпретирует, в итоге результат будет похож на правду, но не то. Исправит-то он конечно быстро, но потом же опять тестировать.
5. Раскатка на среды. О, об этом далекие от программирования люди вообще обычно не думают, но если спросить "как?" не моргнув глазом идут уточнять у ИИ. Через некоторое время обычно сдаются и приходят к идее спихнуть задачу на ИТ-отдел. Ведь вайбкодер сделал своё дело, вайбкодер может идти, а скучные вещи пусть айтишники делают.
Еще можно задавать каверзные вопросы типа "представляешь, захочешь через месяц доработку к своей системе на прод выкатить, а там уже данных дофига внести успели, как делать это будешь?". Тот, кто пропустил фазу проектирования и забыл учесть вопрос с миграциями в БД обычно выглядит в такие моменты очень озадаченным.
А теперь про платформы.
Ребята, 70% любой бизнес-системы это простые CRUD-интерфейсы с накрученной ролевой, по сути красивая обертка над базой данных. ИИ справляется с этим уже очень хорошо, но платформы не сильно отстают. Причем накликивая все это в платформе ты знаешь, что работать оно будет предсказуемо, а в случае с ИИ - проверять еще надо.
Еще 20% бизнес-системы это логика разной степени хитрости. Тут платформам нечем крыть, любой мало-мальски сложный бизнес-процесс потребует разработки, т.к. встроенных средств недостаточно.
Оставшиеся 10% обычно всякие интеграции, хоть тот же SSO для системы или отправка sms/email. В платформе просто задаешь нужные параметры и пользуешься, причем зная, что эту фичу уже оттестировали миллион раз и вероятность словить в этом месте баг крайне низка.
Если считать по баллам, получается плюс-минус одинаково. Да, у платформы есть минус в виде стоимости лицензий, но
1. Есть же полноценные opensource-платформы.
2. У платных есть киллер-фича под названием "саппорт". Если в проде у вас происходит любая НËХ вы просто заводите вендору тикет и не паритесь. Шучу, паритесь конечно если система совсем встала, просто знаете что решать проблему не вам, и это приятно.
Не знаю почему в первом пункте написал "платформы" во множественом числе, на данный момент на рынке таких ровно одна. В общем-то, канал как раз про неё.
Выводы: если вы рассматриваете вариант "навайбкодить себе бизнес-систему" значит денег купить нормальную у вас, скорее всего, нет (разве что $100 на подписку Claude Max). Я бы рекомендовал в таком случае потратить немного времени на изучение opensource-платформы и реализовать свои фантазии на ней, а там где нужно реализовать сложную логику - вот ее реализовать с ИИ.
Тогда можно получить все плюшки платформы в виде стабильности и отлаженных процессов и подружить со скоростью реализации нестандартных хотелок, которые дает ИИ.
Что нравится в NocoBase
Итак, восхваления NocoBase пост.
Сравнивать буду с теми коммерческими платформами, которые удалось потрогать за свою карьеру: MS Dynamics CRM, Creatio/BPMSoft, Bitrix24.
Настройка коллекций (объектной модели)
Вот тут все прям ОЧЕНЬ хорошо. Мало того, что цеплять в систему можно несколько БД (и даже СУБД), даже если ограничиться opensource-лицензией и настраивать все в одном источнике данных испытать нехватку каких-то типов будет практически невозможно. Из коробки поддерживает все виды связей (1-N, N-N и даже 1-1), все стандартные типы, enum'ы с одиночным и мультивыбором, файлы и последовательности. Даже идентификаторы можно лупить нескольких видов, как душа пожелает.
Ролевая (ACL)
Ролевая в NocoBase - моё почтение. С одной стороны обычный RBAC, но тут вам и row-level security (rule-based правда, без возможности шарить отдельные записи), и column-level security. Причем CLS можно настраивать гранулярно для операций создания/чтения/изменения/импорта/экспорта. Я когда увидел был впечатлен.
Если у пользователя несколько ролей, платформа дает выбор: хочешь можно переключаться между ролями, а не хочешь - будет тебе объединение привилегий.
А еще помните, у нас же несколько источников данных может быть? Так вот, права настраиваются отдельно для каждого из них.
Такого вообще нигде не видел.
Да, и там же можно настраивать видимость разделов UI.
Редактор UI
Тут короче есть небольшие непонятки, но сейчас объясню: создавать можно два вида страниц - v1 (Classic) и v2 (Modern).
Плюсы классических страниц - куча виджетов типа календаря, канбана, форм быстрой фильтрации. Но возможностей делать что-то нестандартное там нет.
Плюс модерновых - можно фигачить свои скрипты на RunJS и делать JS-блоки с практически неограниченной функциональностью, а еще можно использовать AI-агентов. Но таких крутых виджетов как у классики уже нет, только самый минимум.
Как я понял, классические страницы и виджеты развиваться не будут, команда сосредоточилась на модерновых.
Самое приятное, что в системе могут рядышком существовать и те и те страницы. Если надо что-то стандартное и быстро - добавляется классическая страница. Если хочется красиво и нестандартно - ИИ напишет, а JS-блок отобразит.
Из стандартных вещей: есть бизнес-правила (скрыть/деактивировать/сделать обязательным поле; отфильтровать выпадающий список). Настраивается мышкой и достаточно гибко. Можно привязывать бизнес-процессы к кнопкам тоже мышкой, или URL подергать какой хочется.
На модерновых страницах через RunJS можно будет еще больше делать, но пока рано.
В принципе, логика разработчиков понятна: зачем городить UI на все возможные сценарии настройки системы, если можно дать возможность запускать JS-код, а его легко нейросеть напишет, если попросить человечьим языком. Лайк.
Редактор бизнес-процессов
Так, ну до Creatio тут далеко, и это даже не BPMN, но все необходимое есть. Благо разработчики не стали тащить сюда какую-нить Camunda а сделали свой довольно простой но функциональный редактор. Может он не такой красивый как у коммерческих платформ, но пока я не испытал недостатка функциональности. Опять же, если чего-то не хватает - к нашим услугам блоки JavaScript/SQL Action и нейросети.
Ограничение бесплатной версии: нет стартового сигнала "вебхук" и возможности использовать подпроцессы, чтобы общую логику туда выносить.
В следующем посте расскажу что не понравилось или не хватило.
Итак, восхваления NocoBase пост.
Сравнивать буду с теми коммерческими платформами, которые удалось потрогать за свою карьеру: MS Dynamics CRM, Creatio/BPMSoft, Bitrix24.
Настройка коллекций (объектной модели)
Вот тут все прям ОЧЕНЬ хорошо. Мало того, что цеплять в систему можно несколько БД (и даже СУБД), даже если ограничиться opensource-лицензией и настраивать все в одном источнике данных испытать нехватку каких-то типов будет практически невозможно. Из коробки поддерживает все виды связей (1-N, N-N и даже 1-1), все стандартные типы, enum'ы с одиночным и мультивыбором, файлы и последовательности. Даже идентификаторы можно лупить нескольких видов, как душа пожелает.
Ролевая (ACL)
Ролевая в NocoBase - моё почтение. С одной стороны обычный RBAC, но тут вам и row-level security (rule-based правда, без возможности шарить отдельные записи), и column-level security. Причем CLS можно настраивать гранулярно для операций создания/чтения/изменения/импорта/экспорта. Я когда увидел был впечатлен.
Если у пользователя несколько ролей, платформа дает выбор: хочешь можно переключаться между ролями, а не хочешь - будет тебе объединение привилегий.
А еще помните, у нас же несколько источников данных может быть? Так вот, права настраиваются отдельно для каждого из них.
Такого вообще нигде не видел.
Да, и там же можно настраивать видимость разделов UI.
Редактор UI
Тут короче есть небольшие непонятки, но сейчас объясню: создавать можно два вида страниц - v1 (Classic) и v2 (Modern).
Плюсы классических страниц - куча виджетов типа календаря, канбана, форм быстрой фильтрации. Но возможностей делать что-то нестандартное там нет.
Плюс модерновых - можно фигачить свои скрипты на RunJS и делать JS-блоки с практически неограниченной функциональностью, а еще можно использовать AI-агентов. Но таких крутых виджетов как у классики уже нет, только самый минимум.
Как я понял, классические страницы и виджеты развиваться не будут, команда сосредоточилась на модерновых.
Самое приятное, что в системе могут рядышком существовать и те и те страницы. Если надо что-то стандартное и быстро - добавляется классическая страница. Если хочется красиво и нестандартно - ИИ напишет, а JS-блок отобразит.
Из стандартных вещей: есть бизнес-правила (скрыть/деактивировать/сделать обязательным поле; отфильтровать выпадающий список). Настраивается мышкой и достаточно гибко. Можно привязывать бизнес-процессы к кнопкам тоже мышкой, или URL подергать какой хочется.
На модерновых страницах через RunJS можно будет еще больше делать, но пока рано.
В принципе, логика разработчиков понятна: зачем городить UI на все возможные сценарии настройки системы, если можно дать возможность запускать JS-код, а его легко нейросеть напишет, если попросить человечьим языком. Лайк.
Редактор бизнес-процессов
Так, ну до Creatio тут далеко, и это даже не BPMN, но все необходимое есть. Благо разработчики не стали тащить сюда какую-нить Camunda а сделали свой довольно простой но функциональный редактор. Может он не такой красивый как у коммерческих платформ, но пока я не испытал недостатка функциональности. Опять же, если чего-то не хватает - к нашим услугам блоки JavaScript/SQL Action и нейросети.
Ограничение бесплатной версии: нет стартового сигнала "вебхук" и возможности использовать подпроцессы, чтобы общую логику туда выносить.
В следующем посте расскажу что не понравилось или не хватило.
Что НЕ нравится в NocoBase
Итак, что же в NocoBase мне не понравилось.
Сразу делаю скидку на то, что не буду учитывать возможности платной версии:
- согласования
- перенос конфигурации
- SSO
- вебхуки
- печатные формы
- согласования
- подпроцессы
- журналы изменений и аудита
- работу в режиме кластера
В моем списке только то, что платными плагинами на данный момент не решается:
1. Отсутствие единого журнала процессов.
Быстро посмотреть, что в системе происходит и где зависло - нельзя. Нужно заходить в каждый бизнес-процесс и смотреть в нем. Удобно? Не то слово.
2. Кейсы (полоска статусов)
Тут прямо совсем все плохо, хотя фича вроде стандартная для других конструкторов. В демке CRM от вендора (которая скорее даже демонстрация возможностей платформы) на странице лида это реализовано прям очень тупо: каждое состояние эмулируется парой кнопок (синяя и серая) и бизнес-правилами их показа и доступности перехода. То есть технически сделать какое-то подобие можно, если знатно упороться.
3. Системные настройки
В лучших традициях Dynamics CRM, если нужно хранить где-то системные настройки - создаешь коллекцию где каждое поле это настройка, и редактируешь в каком-то техническом интерфейсе, в таблице всегда 1 запись. Глупость? А разработчики платформы именно так и реализовали одноименный раздел.
Хотя есть же более-менее нормальные реализации, например в Creatio: одна таблица для перечня системных настроек, еще одна - для их значений, количество столбцов равно количеству возможных типов значений. И сразу настроечка "кешировать". А еще значение настройки благодаря этому можно делать персональным для пользователя. Почему нельзя было так же?
Да, чуть не забыл, есть раздел "Переменные и секреты". Но там только текст и зашифрованный текст.
4. Нельзя сохранять фильтры разделов
Ладно, возможно тут придираюсь, но в некоторых платформах можно один раз настроить расширенный фильтр и сохранить его себе в папку. Делаешь таких несколько и потом просто переключаешься между ними.
Наверное как костыль можно промт для AI-сотрудника сохранить, который будет реестр фильтровать, но решение такое себе.
5. Устройство основной БД
Во-первых, все таблицы коллекций создаются без префиксов. С одной стороны удобно, но с другой - возможны конфликты с системными таблицами и таблицами плагинов, в том числе будущих.
Во-вторых, в основной БД нет внешних ключей между табличками. Сначала подумал, что это только пользовательских коллекций касается, но оказалось их совсем нет. Perplexity пишет что это намеренное архитектурное решение чтобы поддерживать несколько СУБД и облегчить миграции (ну да ну да), а целостность данных гарантирует приложение.
6. Совместная разработка и версионность
Пока настройкой платформы занимается один человек - проблем нет, особенно если сразу на проде. Но, если системой уже начали пользоваться, хочется двух вещей: трекать вносимые изменения и переносить изменения конфигурации между средами dev -> stage -> prod. Со вторым точно поможет плагин Migration Manager из платной версии, но он выгружает архив, а хочется configuration-as-a-code, тогда и с совместной разработкой проблем нет: смержил-залил-раскатал.
Кстати, если Migration Manager'а нет, то решение по накату конфигурации от вендора такое: возьмите полный бекап БД настроенной системы и перенесите его на прод.
7. Нет универсального импорта
Тут примерно как с журналом процессов: можно получить что нужно, только телодвижений совершить придется сильно больше.
В NocoBase чтобы загрузить данные справочника нужно после создания коллекции обязательно настроить по ней UI и включить действие "Импорт", после чего настроить шаблон. Если таких справочников много - у кого-то будет много работы по настройке!
Кстати, импорт умеет отслеживать уникальность импортируемых записей только по первичному ключу, его придется проставлять в шаблонах и следить за неизменностью.
Итак, что же в NocoBase мне не понравилось.
Сразу делаю скидку на то, что не буду учитывать возможности платной версии:
- согласования
- перенос конфигурации
- SSO
- вебхуки
- печатные формы
- согласования
- подпроцессы
- журналы изменений и аудита
- работу в режиме кластера
В моем списке только то, что платными плагинами на данный момент не решается:
1. Отсутствие единого журнала процессов.
Быстро посмотреть, что в системе происходит и где зависло - нельзя. Нужно заходить в каждый бизнес-процесс и смотреть в нем. Удобно? Не то слово.
2. Кейсы (полоска статусов)
Тут прямо совсем все плохо, хотя фича вроде стандартная для других конструкторов. В демке CRM от вендора (которая скорее даже демонстрация возможностей платформы) на странице лида это реализовано прям очень тупо: каждое состояние эмулируется парой кнопок (синяя и серая) и бизнес-правилами их показа и доступности перехода. То есть технически сделать какое-то подобие можно, если знатно упороться.
3. Системные настройки
В лучших традициях Dynamics CRM, если нужно хранить где-то системные настройки - создаешь коллекцию где каждое поле это настройка, и редактируешь в каком-то техническом интерфейсе, в таблице всегда 1 запись. Глупость? А разработчики платформы именно так и реализовали одноименный раздел.
Хотя есть же более-менее нормальные реализации, например в Creatio: одна таблица для перечня системных настроек, еще одна - для их значений, количество столбцов равно количеству возможных типов значений. И сразу настроечка "кешировать". А еще значение настройки благодаря этому можно делать персональным для пользователя. Почему нельзя было так же?
Да, чуть не забыл, есть раздел "Переменные и секреты". Но там только текст и зашифрованный текст.
4. Нельзя сохранять фильтры разделов
Ладно, возможно тут придираюсь, но в некоторых платформах можно один раз настроить расширенный фильтр и сохранить его себе в папку. Делаешь таких несколько и потом просто переключаешься между ними.
Наверное как костыль можно промт для AI-сотрудника сохранить, который будет реестр фильтровать, но решение такое себе.
5. Устройство основной БД
Во-первых, все таблицы коллекций создаются без префиксов. С одной стороны удобно, но с другой - возможны конфликты с системными таблицами и таблицами плагинов, в том числе будущих.
Во-вторых, в основной БД нет внешних ключей между табличками. Сначала подумал, что это только пользовательских коллекций касается, но оказалось их совсем нет. Perplexity пишет что это намеренное архитектурное решение чтобы поддерживать несколько СУБД и облегчить миграции (ну да ну да), а целостность данных гарантирует приложение.
6. Совместная разработка и версионность
Пока настройкой платформы занимается один человек - проблем нет, особенно если сразу на проде. Но, если системой уже начали пользоваться, хочется двух вещей: трекать вносимые изменения и переносить изменения конфигурации между средами dev -> stage -> prod. Со вторым точно поможет плагин Migration Manager из платной версии, но он выгружает архив, а хочется configuration-as-a-code, тогда и с совместной разработкой проблем нет: смержил-залил-раскатал.
Кстати, если Migration Manager'а нет, то решение по накату конфигурации от вендора такое: возьмите полный бекап БД настроенной системы и перенесите его на прод.
7. Нет универсального импорта
Тут примерно как с журналом процессов: можно получить что нужно, только телодвижений совершить придется сильно больше.
В NocoBase чтобы загрузить данные справочника нужно после создания коллекции обязательно настроить по ней UI и включить действие "Импорт", после чего настроить шаблон. Если таких справочников много - у кого-то будет много работы по настройке!
Кстати, импорт умеет отслеживать уникальность импортируемых записей только по первичному ключу, его придется проставлять в шаблонах и следить за неизменностью.
Как ролевая влияет на производительность
Стало интересно, как влияет RLS (row-level security) и CLS (column-level security) на производительность CRUD-операций в коллекциях NocoBase.
Ограничение доступа по коллекциям/сущностям реализуется в любой платформе довольно просто, тут даже неинтересно. А вот RLS/CLS обычно могут затормозить работу с данными довольно заметно.
Традиционно RLS реализуют одним из следующих способов:
- rule-based, когда в настройках коллекции для каждой роли задается фильтр для данных (условие) и система автоматически его применяет на всех запросах.
- data-based, когда система хранит настройки видимости каждой записи в отдельной таблице.
Минусы rule-based: нельзя пошарить конкретную запись пользователю, если по условиям фильтра ему нельзя ее видеть.
Минусы data-based: в каждой сущности должно быть поле Ответственный (или аналог), куда можно записать пользователя/группу/роль, и если нужны хитрые правила определения ответственных на основе атрибутов записи - придется делать бизнес-процессы раздачи прав с хитрой логикой, т.е. в одном месте уже не настроишь ролевую. Плюс платформа может накосячить с реализацией, запихнув все данные RLS всех сущностей в одну таблицу и получить бутылочное горлышко всей ролевой на ровном месте (привет, таблица PrincipalObjectAccess в Dynamics CRM!).
CLS тоже реализуется просто, но почему-то обычно тормозит, и вендоры в документации очень советуют не включать без необходимости, особенно если полей много. Так что если нужно прятать много полей иногда идут на хитрость - все такие поля выносят в отдельную сущность, делают связь 1:1 с основной и ограничивают права уже на эту отдельную сущность.
В Dynamics CRM, Creatio/BPMSoft, Битрикс24 - data-based RLS.
В NocoBase у нас rule-based RLS, причем платформа сразу предлагает настроить и CLS, намекая, что ей это ничего не стоит. Вот это и проверим, результат в следующем посте.
Стало интересно, как влияет RLS (row-level security) и CLS (column-level security) на производительность CRUD-операций в коллекциях NocoBase.
Ограничение доступа по коллекциям/сущностям реализуется в любой платформе довольно просто, тут даже неинтересно. А вот RLS/CLS обычно могут затормозить работу с данными довольно заметно.
Традиционно RLS реализуют одним из следующих способов:
- rule-based, когда в настройках коллекции для каждой роли задается фильтр для данных (условие) и система автоматически его применяет на всех запросах.
- data-based, когда система хранит настройки видимости каждой записи в отдельной таблице.
Минусы rule-based: нельзя пошарить конкретную запись пользователю, если по условиям фильтра ему нельзя ее видеть.
Минусы data-based: в каждой сущности должно быть поле Ответственный (или аналог), куда можно записать пользователя/группу/роль, и если нужны хитрые правила определения ответственных на основе атрибутов записи - придется делать бизнес-процессы раздачи прав с хитрой логикой, т.е. в одном месте уже не настроишь ролевую. Плюс платформа может накосячить с реализацией, запихнув все данные RLS всех сущностей в одну таблицу и получить бутылочное горлышко всей ролевой на ровном месте (привет, таблица PrincipalObjectAccess в Dynamics CRM!).
CLS тоже реализуется просто, но почему-то обычно тормозит, и вендоры в документации очень советуют не включать без необходимости, особенно если полей много. Так что если нужно прятать много полей иногда идут на хитрость - все такие поля выносят в отдельную сущность, делают связь 1:1 с основной и ограничивают права уже на эту отдельную сущность.
В Dynamics CRM, Creatio/BPMSoft, Битрикс24 - data-based RLS.
В NocoBase у нас rule-based RLS, причем платформа сразу предлагает настроить и CLS, намекая, что ей это ничего не стоит. Вот это и проверим, результат в следующем посте.
load-test-report.md
9 KB
Продолжение предыдушего поста.
Для тестов сделал следующее:
1. Основная таблица Order на 50 полей разных типов, из них 9 справочных many-to-one).
2. Подчиненная таблица OrderItem на 10 простых полей.
3. 9 таблиц справочников.
Далее наполнена БД:
- в справочники по 1000 записей
- в Order - 1 млн записей
- в OrderItem - от 5 до 20 записей, итого получилось 10.5 млн записей на всех
В системе настроено три роли:
- full access: условный админ, ограничения на коллекции не установлены - видит все сущности и все поля.
- rls: эмуляция регионального менеджера - для основной таблицы order установлены ограничения по значению связанного справочника Регион - видит только заказы одного конкретного региона, при этом ограничений по видимости полей нет.
- rls+cls: аналогично предыдущему, только пользователь теперь видит только половину полей коллекции Order.
Все три роли выданы одному пользователю, при обращении к API нужная роль задается заголовком X-Role. Объединение ролей, разумеется, выключено.
Оборудование:
- виртуалка под PostgreSQL: 4 CPU, 4 Gb RAM, SSD-диск.
- виртуалка под NocoBase: 2 CPU, 4 Gb RAM, SSD-диск.
- виртуалка под нагрузочный тест: 8 CPU, 8 Gb RAM, SSD.
Все три виртуалки на одном хосте.
Нарезать больше ресурсов не проблема, просто тестовый стенд не смог выбрать даже эти. Конфиг PostgreSQL оптимизирован под железо.
Нагрузочный тест запускался для 30 и 50 параллельных пользователей. Если что это не то же самое что и RPS, метрика RPS гораздо ниже потому что пользователи во время работы не тыкают по кнопкам системы непрерывно.
Напоминаю, цель теста - выяснить, как настройки видимости коллекций/полей влияют на производительность, т.е. абсолютные цифры сейчас не особо важны. Сравнение с другими платформами отдельно проведу.
Файл с отчетом во вложении к посту, а если вкратце, результаты такие:
Включение RLS негативного влияния на производительность не оказывает.
В общем-то, даже наоборот - за счет rule-based выборка данных сужается, из-за чего запросы становятся быстрее. Но есть нюанс: если для проверки правила системе придется сделать JOIN на очень жирную таблицу, деградация производительности все же может быть. Именно это и происходит обычно в системах с data-based RLS: там информация о доступности конкретной записи конкретному пользователю/группе хранится в отдельной таблице, т.е. таких записей кратно больше чем записей исходной таблицы, и при каждом обращении СУБД будет делать тяжелый JOIN. В моем тесте для проверки доступности нужно было сделать JOIN на таблицу всего из 1000 записей.
Включение CLS негативного влияния на производительнсоть тоже не оказывает.
И опять все наоборот - запросы даже ускоряются, потом что выбирать из БД надо меньше данных, сериализовать и отправлять по сети - тоже. А определение какие столбцы выбирать из БД ORM-фреймворк системы делает довольно быстро.
Вот такие вот внезапные и приятные выводы.
В следующей серии сравним абсолютные цифры производительности с Creatio.
Для тестов сделал следующее:
1. Основная таблица Order на 50 полей разных типов, из них 9 справочных many-to-one).
2. Подчиненная таблица OrderItem на 10 простых полей.
3. 9 таблиц справочников.
Далее наполнена БД:
- в справочники по 1000 записей
- в Order - 1 млн записей
- в OrderItem - от 5 до 20 записей, итого получилось 10.5 млн записей на всех
В системе настроено три роли:
- full access: условный админ, ограничения на коллекции не установлены - видит все сущности и все поля.
- rls: эмуляция регионального менеджера - для основной таблицы order установлены ограничения по значению связанного справочника Регион - видит только заказы одного конкретного региона, при этом ограничений по видимости полей нет.
- rls+cls: аналогично предыдущему, только пользователь теперь видит только половину полей коллекции Order.
Все три роли выданы одному пользователю, при обращении к API нужная роль задается заголовком X-Role. Объединение ролей, разумеется, выключено.
Оборудование:
- виртуалка под PostgreSQL: 4 CPU, 4 Gb RAM, SSD-диск.
- виртуалка под NocoBase: 2 CPU, 4 Gb RAM, SSD-диск.
- виртуалка под нагрузочный тест: 8 CPU, 8 Gb RAM, SSD.
Все три виртуалки на одном хосте.
Нарезать больше ресурсов не проблема, просто тестовый стенд не смог выбрать даже эти. Конфиг PostgreSQL оптимизирован под железо.
Нагрузочный тест запускался для 30 и 50 параллельных пользователей. Если что это не то же самое что и RPS, метрика RPS гораздо ниже потому что пользователи во время работы не тыкают по кнопкам системы непрерывно.
Напоминаю, цель теста - выяснить, как настройки видимости коллекций/полей влияют на производительность, т.е. абсолютные цифры сейчас не особо важны. Сравнение с другими платформами отдельно проведу.
Файл с отчетом во вложении к посту, а если вкратце, результаты такие:
Включение RLS негативного влияния на производительность не оказывает.
В общем-то, даже наоборот - за счет rule-based выборка данных сужается, из-за чего запросы становятся быстрее. Но есть нюанс: если для проверки правила системе придется сделать JOIN на очень жирную таблицу, деградация производительности все же может быть. Именно это и происходит обычно в системах с data-based RLS: там информация о доступности конкретной записи конкретному пользователю/группе хранится в отдельной таблице, т.е. таких записей кратно больше чем записей исходной таблицы, и при каждом обращении СУБД будет делать тяжелый JOIN. В моем тесте для проверки доступности нужно было сделать JOIN на таблицу всего из 1000 записей.
Включение CLS негативного влияния на производительнсоть тоже не оказывает.
И опять все наоборот - запросы даже ускоряются, потом что выбирать из БД надо меньше данных, сериализовать и отправлять по сети - тоже. А определение какие столбцы выбирать из БД ORM-фреймворк системы делает довольно быстро.
Вот такие вот внезапные и приятные выводы.
В следующей серии сравним абсолютные цифры производительности с Creatio.