Комментарии 6
В нашем случае это описание хранится в low-code:
{
"rule": {
"$match": {
"pattern": "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{1,1000}$"
}
},
"events": [
"onUpdate",
"onBackend"
]
}
Каким боком это low-code, если это самый настоящий код?
[
"return form.statusChanges.pipe(",
" startWith(form.status),",
" filter((status) => status !== 'PENDING'),",
" map(() => {",
" // Формируем ответ с ошибками, если они есть",
" const errors = this.buildErrors(form);",
" return this.buildResponse(form, data, errors);",
" })",
");",
]
Тогда это тоже low-code.
Нет. Второе это код. Первое это лишь конфиг, но не код.
В обсуждениях с командами мы называем это "схема", "конфигурация", "лоукод", "джсончик", тут смысл один - это схема, которую пишут аналитики, которая настраивает поведение кода, который пишут программисты. Поэтому я посчитал уместным назвать его low-code. Но с Вами я так же соглашусь, что это самый настоящий код, в названии low-code так и сказано, что это код =)
Приветствую! Как вы решаете (и решаете ли вообще) проблемы производительности. Что мы видим:
JSON который нужно гонять по сети и он явно не может быть компактным для развесистых форм. Пользователи мобильных устройств не скажут нам спасибо.
интерпретатор "конфигурации" в сущности, понятные фреймворку. В данном случае это формы angular. В это время пользователь будет смотреть на наш классный лоадер?
переизбыток и компрометация информации о валидации. Мы показываем в открытом виде, то что будем проверять на сервере, кроме того клиент узнает то, что будет проверяться ТОЛЬКО на сервере. Выглядит как дыра и повод для размышления для пентестеров.
"Чаще всего эти задачи передаются бэкенд и фронтенд разработчикам, которые реализуют одну и ту же логику. " чаще всего, но всегда. И даже в вашем примере мы видим валидаторы, только для бекенда. Как будто, если вы хотите писать валидацию один раз, то ее нужно делать только на сервере, а на клиенте только отображать ошибки.
И еще вопрос со звездочкой: почему не использовали кодогенерацию? Кажется, что формализованные формы можно шаблонно запрограммировать и, увеличив время "сборки" приложения, дать огромный прирост производительности в рантайме клиентского приложения.
Добрый день! В данном контексте мы не испытывали проблем с производительностью, этому может быть несколько причин:
- в большинстве случаев мы получаем схему и данные за один запрос, что позволяет пользователю сразу получить приложение готовое к использованию, не ждать отдельно загрузку данных
- наши приложения это чаще всего сложные B2B приложения и основное место работы ПК, при этом если требуется мобильная версия, то, несмотря на адаптив из коробки, готовятся отдельные формы - менее нагруженные и другим пользовательским опытом
- интерпретация "конфигурации" происходит на столько быстро, что позволяет нам на текущий момент не задумываться об этом, реализация близка к обычному созданию контролов реактивной формы
- знание о проверках должно быть у пользователя, если он не понимает по каким правилам заполнять данные, то ему будет сложно пользоваться приложением. естественно мы понимаем, что в конфигурации (не только валидации, а в целом) не должно быть чувствительных данных, но это уже к вопросу реализации. Но мысль хорошая, возьмем себе в беклог задачу по исключению схемы, которая предназначена только для backend =)
Из моего опыта: валидации, которые можно переиспользовать, все же преобладают. Данный пример специально выбран, чтобы показать, что не всегда можно переиспользовать реализацию полностью. Думаю очевидно, что проверки на обязательность, формат строк, зависимых полей и т.д. значительно больше в системе, и оставить их все только на бекенд, значит значительно ухудшить пользовательский опыт, особенно, когда мы говорим о сложных формах, которые могут состоять из многих связанных блоков.
Кодогенерацию на мой взгляд сложнее поддерживать и развивать. Если мы говорим об использовании кодогенерации для дальнейшего развития в коде (а это мне кажется основным преимуществом кодогенерации, или я что-то упускаю?), то после первого изменения руками мы не сможем использовать тот же механизм генерации из-за возможных коллизий.
И по сути наш подход близок - каждому функциональному блоку конфигурации соответствует написанный код, из которых наши аналитики настраивают полноценные приложения, по сути мы исключили промежуточное звено:
- случае с кодогенерацией у нас есть A -> B -> C, где A - конфигурация, B - кодогенератор, C - код, который исполняется
- в нашем подходе у нас есть A -> C, где A - конфигурация, C - код, который исполняется, просто A говори как именно код будет работать, будь то визуальный компонент или функция. При этом мы имеем точку расширения, мы всегда можем добавить блок любого размера со своей конфигурацией
Зачем нам Node.js или Angular на бэкенде