Добрый день! В данном контексте мы не испытывали проблем с производительностью, этому может быть несколько причин:
- в большинстве случаев мы получаем схему и данные за один запрос, что позволяет пользователю сразу получить приложение готовое к использованию, не ждать отдельно загрузку данных
- наши приложения это чаще всего сложные B2B приложения и основное место работы ПК, при этом если требуется мобильная версия, то, несмотря на адаптив из коробки, готовятся отдельные формы - менее нагруженные и другим пользовательским опытом
- интерпретация "конфигурации" происходит на столько быстро, что позволяет нам на текущий момент не задумываться об этом, реализация близка к обычному созданию контролов реактивной формы
- знание о проверках должно быть у пользователя, если он не понимает по каким правилам заполнять данные, то ему будет сложно пользоваться приложением. естественно мы понимаем, что в конфигурации (не только валидации, а в целом) не должно быть чувствительных данных, но это уже к вопросу реализации. Но мысль хорошая, возьмем себе в беклог задачу по исключению схемы, которая предназначена только для backend =)
Из моего опыта: валидации, которые можно переиспользовать, все же преобладают. Данный пример специально выбран, чтобы показать, что не всегда можно переиспользовать реализацию полностью. Думаю очевидно, что проверки на обязательность, формат строк, зависимых полей и т.д. значительно больше в системе, и оставить их все только на бекенд, значит значительно ухудшить пользовательский опыт, особенно, когда мы говорим о сложных формах, которые могут состоять из многих связанных блоков.
Кодогенерацию на мой взгляд сложнее поддерживать и развивать. Если мы говорим об использовании кодогенерации для дальнейшего развития в коде (а это мне кажется основным преимуществом кодогенерации, или я что-то упускаю?), то после первого изменения руками мы не сможем использовать тот же механизм генерации из-за возможных коллизий.
И по сути наш подход близок - каждому функциональному блоку конфигурации соответствует написанный код, из которых наши аналитики настраивают полноценные приложения, по сути мы исключили промежуточное звено:
- случае с кодогенерацией у нас есть A -> B -> C, где A - конфигурация, B - кодогенератор, C - код, который исполняется
- в нашем подходе у нас есть A -> C, где A - конфигурация, C - код, который исполняется, просто A говори как именно код будет работать, будь то визуальный компонент или функция. При этом мы имеем точку расширения, мы всегда можем добавить блок любого размера со своей конфигурацией
В обсуждениях с командами мы называем это "схема", "конфигурация", "лоукод", "джсончик", тут смысл один - это схема, которую пишут аналитики, которая настраивает поведение кода, который пишут программисты. Поэтому я посчитал уместным назвать его low-code. Но с Вами я так же соглашусь, что это самый настоящий код, в названии low-code так и сказано, что это код =)
Добрый день! В данном контексте мы не испытывали проблем с производительностью, этому может быть несколько причин:
- в большинстве случаев мы получаем схему и данные за один запрос, что позволяет пользователю сразу получить приложение готовое к использованию, не ждать отдельно загрузку данных
- наши приложения это чаще всего сложные B2B приложения и основное место работы ПК, при этом если требуется мобильная версия, то, несмотря на адаптив из коробки, готовятся отдельные формы - менее нагруженные и другим пользовательским опытом
- интерпретация "конфигурации" происходит на столько быстро, что позволяет нам на текущий момент не задумываться об этом, реализация близка к обычному созданию контролов реактивной формы
- знание о проверках должно быть у пользователя, если он не понимает по каким правилам заполнять данные, то ему будет сложно пользоваться приложением. естественно мы понимаем, что в конфигурации (не только валидации, а в целом) не должно быть чувствительных данных, но это уже к вопросу реализации. Но мысль хорошая, возьмем себе в беклог задачу по исключению схемы, которая предназначена только для backend =)
Из моего опыта: валидации, которые можно переиспользовать, все же преобладают. Данный пример специально выбран, чтобы показать, что не всегда можно переиспользовать реализацию полностью. Думаю очевидно, что проверки на обязательность, формат строк, зависимых полей и т.д. значительно больше в системе, и оставить их все только на бекенд, значит значительно ухудшить пользовательский опыт, особенно, когда мы говорим о сложных формах, которые могут состоять из многих связанных блоков.
Кодогенерацию на мой взгляд сложнее поддерживать и развивать. Если мы говорим об использовании кодогенерации для дальнейшего развития в коде (а это мне кажется основным преимуществом кодогенерации, или я что-то упускаю?), то после первого изменения руками мы не сможем использовать тот же механизм генерации из-за возможных коллизий.
И по сути наш подход близок - каждому функциональному блоку конфигурации соответствует написанный код, из которых наши аналитики настраивают полноценные приложения, по сути мы исключили промежуточное звено:
- случае с кодогенерацией у нас есть A -> B -> C, где A - конфигурация, B - кодогенератор, C - код, который исполняется
- в нашем подходе у нас есть A -> C, где A - конфигурация, C - код, который исполняется, просто A говори как именно код будет работать, будь то визуальный компонент или функция. При этом мы имеем точку расширения, мы всегда можем добавить блок любого размера со своей конфигурацией
В обсуждениях с командами мы называем это "схема", "конфигурация", "лоукод", "джсончик", тут смысл один - это схема, которую пишут аналитики, которая настраивает поведение кода, который пишут программисты. Поэтому я посчитал уместным назвать его low-code. Но с Вами я так же соглашусь, что это самый настоящий код, в названии low-code так и сказано, что это код =)