Schema Driven UI подход в enterprise-разработке

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

В докладе разберем практический опыт долгоживущего Schema Driven UI. Мы поговорим о подходе, где формы описываются DSL/JSON-схемами, редактируются через конструктор интерфейсов, собираются в артефакт, а клиентская часть читает схему и строит интерфейс из доступного набора компонентов. Такой подход ускоряет разработку типовых форм и настроек, повышает единообразие UI и помогает мигрировать большие продуктовые сценарии без постоянного переписывания однотипного фронтенд-кода.

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

В финале свяжем Schema Driven UI с трендом генерации интерфейсов с помощью AI. Если AI будет собирать интерфейсы, ему нужен не бесконечный простор для генерации JSX, а безопасный ограниченный язык: набор доступных компонентов, схемы данных, правила проверки, ограничения и заранее описанные безопасные действия. Поэтому Schema Driven UI может стать не конкурентом AI, а платформенным слоем, который делает генерацию интерфейсов управляемой.

Доклад будет полезен тем, кто строит корпоративный фронтенд, внутренние платформы, дизайн-системы, конструкторы форм или думает о внедрении интерфейса как конфигурации. Основной фокус — не теория и не рекламный рассказ, а честный опыт: где подход ускоряет продукт, где начинает тухнуть и какие инженерные решения нужны, чтобы он прожил дольше одного красивого MVP.