Когда три года назад в июле к нам пришли с просьбой сделать фронтенд для маленькой системы документооборота, мы оценили задачу в полгода… ТЗ принесли на создание более 1000 разных форм. Обещанные нами полгода перестали казаться спокойными.

Через пару недель к задаче добавились две крупные системы на 1С и ещё несколько в разработке, с бэкендами на С++ и Java. Объём работы стал выглядеть неподъёмно. Плюс основное требование — всё должно быть в едином интерфейсе. Так мы поняли, что нужно браться за универсальное решение, которое «скушает» любой бэкенд.

image
Импортозамещённый JSON

Эта история о том, как команда из 16 человек разработала Атом.Форму — продукт, который уже работает для шести крупных систем в «Росатоме», и их количество постоянно растёт. А срок создания фронта теперь занимает 2–3 недели для маленьких и несколько месяцев для развесистых систем.

Успеть принять верное решение


История про экспоненциальный рост задачи возникла из-за необходимости перенести на новые технологии три системы, которые входят в Единую систему закупок «Росатома». Поэтому мы подступились к задаче сначала с командами 1С, но держали в уме, что решение должно масштабироваться и под другие технологии.

Объёмы закупочных процедур «Росатома» титанические — исчисляются десятками тысяч документов, и поначалу для перехода планировалось задействовать три отдельные команды. Но в процессе решили, что делать сразу всё в едином ключе будет правильнее.

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

Подходящего готового ПО на рынке не было. Нанять людей мы банально не успевали, поскольку макеты надо было отдать через 3–4 месяца.

Так появилась славная мысль, что у нас бэкендеров больше, чем фронтендеров, и все они на 1С, плюсах и Java. А в 1С, например, есть свой инструмент по вёрстке клиентской формы. Но 1С всем клиентам не поставишь, это практически невыполнимо.

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

Что делали и как решение стало универсальным


Для начала мы попросили разработчиков бэкенда написать небольшую программку на 1С, которая будет проходить по их собственным формам, и в «каком-нибудь формате» выгрузить описание форм с оформлением этих формочек (кнопки, элементы и т. п.). А нам оставалось только придумать, как это отобразить.

Пример:

image

Для этого мы разработали веб-клиента на JavaScript, который отображает формы на основе описаний в формате JSON, чтобы избежать ситуации «Давайте сверстаем HTML, вставим туда JavaScript и подумаем о бэкенде». Получился такой импортозамещённый JSON на русском. Работает это так: бэкенд отправляет описание того, что, куда и как показать. А фронт этим занимается, причём одинаково хорошо на любых устройствах.

Из забавного: многие атрибуты мы теперь называем по-русски, но старые привычки сказываются. Поэтому иногда в JSON-полях встречаются фразы вроде «отослать гет-постом этот запрос тру фолс», или «“ПриКликеSendREST”: true». Это весело. И при этом работает, и не надо много думать над переводом.

image

В общем, Атом.Форма позволяет работать с бэкендами, написанными на любом языке. Мы просто разворачиваем Docker-контейнер с уже собранной Атом.Формой, в параметрах запуска контейнера указываем адрес бэкенда, генерим на бэкенде JSON и скармливаем этот файл браузеру в ответ на запрос. Вуаля! И на одну страницу можно собирать данные из разных бэкендов.

Мы избавили сервер от забот с вёрсткой и адаптацией — теперь бэкенду не нужно знать, как работает CSS, учитывать мобильные устройства и управлять библиотеками. Он просто говорит: «Вот данные, сделайте красиво», и фронт делает. Причём если нужно, чтобы данные собирались из нескольких систем одновременно, то это тоже у нас учтено: мы вытягиваем их в едином интерфейсе, так что пользователь видит цельную картину.

Было:

image

Стало:

image

Из ключевых моментов: фронт не тянет с бэкенда никакой код, только данные. И на клиенте нет бизнес-логики, только интерфейс. Система занимается только отображением того, что получила со стороны. У неё нет встроенных формочек по работе с товарами, нет готовых компонентов по работе с профилями пользователей или документами. Она умеет быстро и красиво разместить все нужные элементы и позаботиться о том, чтобы они одинаково выглядели, вне зависимости от того, из какого бэкенда получены данные.

Разработчикам бэкенда не надо задумываться о вёрстке фронтенда. Они занимаются своим делом и просто говорят, что нужна такая форма в интерфейсе, такие кнопки, grid, надписи и т. п., а Атом.Форма это всё отображает. Кроме того, она собирает пользовательские действия, клики, движения мышкой, перетаскивания и формирует запрос в таком же виде обратно в сторону бэкенда, он это дело обрабатывает и отвечает.

Интерфейс мы поначалу назвали GAP (Greenatom Application Platform), поскольку он заполнял собой зазор между пользователем и бэкендом. Позже мы переименовали GAP в Атом.Форму, а в октябре 2021-го полностью выделили код в отдельный репозиторий.

Сложности и как мы их преодолевали


Проблемы начались сразу, как мелкие, обычные, так и более серьёзные. Например, читаем строчку в ТЗ и начинаем думать: «А что, собственно, здесь имеется в виду?» Находим человека, он расшифровывает: «Я хотел, чтобы здесь была диаграмма Ганта». Побежали её искать, через какое-то время поняли, что готовая нам не подойдёт, и написали сами. И так не один раз.

Вначале мы думали, что наберём опенсорсных библиотек, склеим из них что-то подходящее в качестве первого варианта. Сделали. Но когда начали прогонять нагрузочные тесты, поняли, что многие из таких решений нам не подходят: одни слишком навороченные, у других — проблемы с лицензиями, третьи перестают поддерживаться и т. д. В итоге взяли за основу Vue2 framework, потом планово перевели на Vue3, и в этой миграции опять проявилось преимущество принятого подхода. Бэкенд-системам ни строчки не пришлось менять у себя, плюс взяли несколько готовых опенсорс-решений по некоторым компонентам (диаграммы-графики линейные, гистограммы и т. д.). Впоследствии практически все компоненты были заменены на собственные реализации. Особенно это коснулось сложных компонент, например, всё той же диаграммы Ганта. Да-да, многие их почему-то любят.

Более сложная проблема всплыла на вопросе с уведомлениями для индивидуальных пользователей: «Вот я сижу, мышкой вожу туда-сюда, а вдруг у меня окошечко всплыло. Прямо из сервера в браузере. В 1С я же могу в клиенте это получить, чтобы всё автоматически происходило?» В 1С это понятно, как сделать в своём клиенте, а как это реализовать в браузере?

Решили прикрутить веб-сокеты. Всё получилось. Выдохнули. Запустили нагрузочное тестирование и через какое-то время упёрлись в бетонный забор. Всё упало, поскольку при четырёх тысячах пользователей (а у нас их уже даже больше) на нашем проксирующем сервере, раздающем Атом.Форму (мы использовали Nginx), стал кончаться пул TCP-соединений. Он просто перестал их открывать. Сначала решили сделать два таких сервера Nginx и распараллелить задачи, но не смогли найти подходящий балансировщик, который работал бы с веб-сокетами. Ещё по ходу дела выяснилось, что технологию веб-сокетов не любят в ИБ, поскольку нельзя фильтровать трафик и смотреть возможные утечки. Веб-сокеты — это, в сущности, канал выдачи информации наружу, который сложно контролировать. Пришлось переходить на технологию отправки уведомлений от сервера к веб-браузеру в виде DOM-событий Server-Sent Events (SSE). А это всё время, которого и так в обрез. Но именно здесь проявилось преимущество нашей концепции разделения фронтальной части и бэкенда. Переход с веб-сокетов на SSE для бэкенда прошёл спокойно и незаметно для бэкенд-разработчиков.

С ещё одной значительной проблемой мы столкнулись, когда начали склеивать несколько разных бэкендов в целостный интерфейс, — это привычки пользователей. У каждого заказчика были свои «хочу»: кому-то хочется красную кнопку, другому — зелёную, третьему — треугольную в рамочке…

Ключом к синхронизации таких пожеланий стали регулярные «системные сходки». Садимся все вместе и обсуждаем: «Вот, ребята, с завтрашнего дня кнопка не просто нажимается, но и подпрыгивает». Обратная связь вначале всегда полярная: «Не надо!», «Давайте попробуем!», «А можно, чтобы она ещё пела?». В итоге консенсус выглядит примерно так: «Окей, пусть подпрыгивает, но только немного».

С каждым новым бэкендом обсуждений становится больше, а вводные от заказчиков — амбициознее. Собрать всё это воедино и прийти к единому решению — это самое сложное. Но у нас пока получается.

Из-за того, что нам надо было очень быстро показать MVP, мы с 2021 года продолжаем заниматься улучшениями и всё ещё часто рефакторим, потому что работали, что называется, с колёс. Каждую идею, которую хотели реализовать разработчики бэкенда, оперативно обсуждали, быстро кодили и выводили на тестирование.

Большим плюсом было то, что мы с бэкендом работали независимо и нам не приходилось ждать друг друга из-за того, что работа шла с разной скоростью.

Реакция пользователей


Атом.Форма уже второй год работает в проде. Наши пользователи, как это бывает обычно, делятся на две категории: «Верните, как было» и «О, круто, вы молодцы». Первая — это люди, которые привыкли к предыдущей системе. Вторая — это те, кому всё нравится, особенно то, что интерфейс един для разных систем, везде всё одинаково работает.

При работе с пользователями, привыкшими к старой системе, выяснилось, например, что большое количество данных выгружалось в Excel и люди там с ними работали. Мы очень удивились и предложили сделать кнопочку, которая будет выполнять нужный функционал без необходимости обращаться в Excel. Вместе с разработчиками бэкенда сделали компоненты по генерации отчётов, и они у нас сейчас встроенные. Градус непринятия заметно снизился. Кто-то даже стал находить в новом радость.

Так потихоньку, шаг за шагом, мы обогащаем пользовательский интерфейс и бэкенд удобными технологиями и компонентами.

Лучше всего к новой системе отнеслись разработчики бэкенда. Для них это просто подарок, поскольку им теперь не надо влезать в параллельную вселенную с её JavaScript’ами. Достаточно отгрузить тот самый импортозамещённый JSON-файл нам в систему, а дальше их уже это не касается — крутите, вертите, лампочки зажигайте. Бэкендеры теперь к нам приходят с пожеланиями, и им не надо знать, как всё работает с разными мобильными устройствами, за них всё делает Атом.Форма.

Сильно упростились взаимоотношения с заказчиком у аналитиков и дизайнеров. Потому что у нас накопилась относительно большая галерея готовых компонентов, с помощью которых мы легко удовлетворяем их потребности. Сейчас мы делаем свой серверный продукт, который должен заменить Figma и ещё сильнее упростить взаимодействие с заказчиком, поскольку сможем вместе с ним быстро набросать нужную форму и тут же её протестировать.

Пример, как это выглядит:

image

После вывода в прод мы столкнулись с большим интересом внутренних заказчиков корпорации. Когда люди из бизнеса узнали, что появилась возможность буквально за несколько дней или недель получить работающий макет, который сразу можно потестить на реальных данных, появилось много желающих воспользоваться нашими услугами. У нас же в корпорации очень много разных систем, и все хотят быстро, комфортно, да ещё желательно с телефона.

Что получилось в результате


В Атом.Форме нам удалось объединить фронтенд-разработчиков, отказаться от набора дополнительных сотрудников при реализации масштабной задачи, сэкономить время, которое раньше уходило на синхронизацию команд, и ресурсы, которые надо было бы затратить на наём.

Мы сделали целостный пользовательский интерфейс, который объединил несколько разных систем в рамках одного single-page приложения. Во фронтенде в одной форме могут присутствовать компоненты от разных систем. Пользователь, который начинает работать с одной системой, может переключиться на другую, и это не составит ему труда.

Старый интерфейс:

image

Новый интерфейс:

image

Атом.Форма абстрагирована от бэкенда, и нам теперь неважно, работаем ли мы с 1С или какой-то другой системой. Мы нарастили функционал, ввели асинхронные вызовы и асинхронные ответы. Например, когда пользователь хочет загрузить большую таблицу, а запрос долго выполняется, бэкенд может сперва загрузить её начало. А как только получит результат в асинхронном фоновом режиме, может добавить данные в конкретную страничку в конкретную форму в браузере.

Система позволила разработчикам фронтенда наконец отказаться от формашлёпства — создания бесконечных похожих друг на друга форм. Теперь все могут заниматься более интересными вещами, не тратить силы и время на рутину и разрабатывать новые компоненты. И, наконец, мы смогли очень резко сократить сроки time-to-market, теперь новые проекты могут выполняться очень быстро, условно говоря — задача будет выполняться не годы, а месяцы, а то и недели.

Ещё один из плюсов этой технологии — когда мы исправляем или добавляем какой-то функционал в движок системы, мы обогащаем разом все проекты. То есть не надо в каждом отдельном проекте править все формы и добавлять новый компонент или какие-то адаптации.

Вот простой показательный пример. Мы как-то пытались полечить для фронта одну ошибку, она была связана с отображением длинных чисел — когда счёт шёл на триллионы, там число вылезало за край. То есть 1–2 цифры обрезались, не влезали, пары нулей в конце не видно, и надо было сделать корректное визуальное отображение этого длинного числа. Когда мы починили, оно везде стало хорошо отображаться сразу у всех.

За счёт того, что слой абстракции введён между бэком и фронтом, мы можем менять на ходу эти выскакивающие календарики, датапикеры или их дизайн. Работе бэкенда при этом оно вообще не мешает — у них всё будет работать.

А что дальше


Сейчас мы оформляем Атом.Форму как самостоятельный продукт и регистрируем в реестре отечественного ПО. Уже отгружаем документы в Роспатент.

Ещё мы сделали десктопное приложение, где Атом.Форма упакована в качестве фронтальной штучки, и есть идея взять эту систему и дать другим командам внутри компании поиграться. Несколько подразделений уже адаптировали её под свои бэкенды. Всё собирается в едином интерфейсе, и мы сейчас обсуждаем, как всё это правильно сегментировать: кому версию лайт, кому — энтерпрайз, а кому — опенсорс.

И да, в планах не только делиться этим инструментом, но и продавать его наружу. Пусть наша Атом.Форма поработает не только на нас, но и на мир.

Комментарии (13)


  1. strokoff
    26.12.2024 07:54

    Хочу начать с извинений, но не смог пройти мимо. Кровь из глаз до сих пор и нервный тик на сегодняшний день обеспечены. Неужели у вас там ни у кого глаз не дернулся? Столько ошибок в верстке макетов на фоне статьи про достижения на фронтенде - это просто какой-то испанский стыд

    Вам жалко отступов? Почему кнопки слились с краями, вас не пугает кнопка на которой НЕ вместилось 3 СТРОКИ?! Или выравнивание текста относительно иконок. А перенос 3 слов "Мессенджер Atom Space" на 4 строки? это же все так легко поправить
    Вам жалко отступов? Почему кнопки слились с краями, вас не пугает кнопка на которой НЕ вместилось 3 СТРОКИ?! Или выравнивание текста относительно иконок. А перенос 3 слов "Мессенджер Atom Space" на 4 строки? это же все так легко поправить

    Или вот еще пример нового интерфейса вашего

    Денег на выравнивание текста не хватило? Кто и как принимал это? Молчу уже про то, что дизайн кончился сразу после шапки сайта и в целом на уровне бесплатного темплейта для WordPress
    Денег на выравнивание текста не хватило? Кто и как принимал это? Молчу уже про то, что дизайн кончился сразу после шапки сайта и в целом на уровне бесплатного темплейта для WordPress

    Зато

    ПриКликеSendREST

    Смешно было бы, если бы не было так грустно(


    1. varsa Автор
      26.12.2024 07:54

      Про первый скриншот — это редактор, там всё как есть — это так и надо. То есть как раз за счет этого редактора мы и находим косяки в верстке.

      Про второй скрин, нового интерфейса — да, мы в курсе того, что там не выровнен текст под поле с кнопкой «найти». Это такой исторический казус. Благодаря этому казусу появились свойства и возможность отображать фоновые изображения в Группах элементов. Но на сайте на титульной странице этого еще не переделывали.

      Ну и грустить не стоит, «ПриКликеSendREST» — для нас это решило проблему с наименованиями атрибутов.


  1. KSLcom
    26.12.2024 07:54

    Свой велосипед это хорошо.


  1. fcrng
    26.12.2024 07:54

    Статья написана настолько лаконично и вкусно, что так и тянет прочесть еще одну.
    Но из технического, в ней приложен лишь кусок json на кириллице, и упомянут Vue.
    До конца так и не понял, что из себя представляет решение.
    Единый фронт благодаря схемам, а разновидности компонентов которые в них могут быть указаны создаются уже кодом, через фреймворк (Vue 3).
    Это все решение? Лечим ui благодаря схемам?
    Или пришлось пойти куда-то дальше, и написать свой фреймворк или еще что-то такое?


    1. varsa Автор
      26.12.2024 07:54

      До конца так и не понял, что из себя представляет решение.

      Это программа на JavaScript, упакованная в Docker контейнер. Внутри много компонентов — элементов, внешними видом и поведением которых можно управлять через импортозамещенный Json. В основе Vue3, да и все остальное — это наш «какбЭфреймворк-Движок». Не только UI, но и UX. Это и обработка событий на элементах, и генерация запросов в формате «Импортозамещенного JSon» обратно в бэкенд.


      1. Writer4
        26.12.2024 07:54

        Можно какие-нибудь подробности про возможности конфигурирования форм в плане например показа разного набора полей после выбора какого-нибудь значения поля, например после выбора типа клиента для физ. и юр. лиц показывать разные наборы атрибутов. Как сделана валидация?


        1. varsa Автор
          26.12.2024 07:54

          В Атом.Форме есть сущности — Элемент Формы, Данные, Действие.

          Элемент формы — это то, что видно на экране с каким-то дизайн-оформлением. Есть блок, связанный с так называемым «Условным оформлением». Это набор правил, при срабатывании которых Атом.Форма самостоятельно меняет Оформление, Видимость, Доступность, Редактибельность и т. д. Можно прислать заранее все поля, и показывать или не показывать их в зависимости от Данных. Это первый способ интерактивного изменения формы без обмена с бэкендом.

          У каждого элемента могут быть разные события. Для события описываются действия, которые надо выполнить. Есть Действия-Команды, которые отправляются в бэкенд, а есть «ПредопределенныеДействия», и тогда можно при нажатии на кнопку выполнить команду «ДобавитьЭлементФормы» или «ОбновитьДанныеФормы». Предопределенные действия это второй способ интерактивности.

          Эти же команды могут прилететь в ответе от бэкенда на Действие-Команду. Это третий способ добавить интерактивности и динамичности в формы.

          На примере ниже — пример описания действия запроса бэкенду.

          {
            "ЭлементыФормы": [
              {
                "ТипЭлемента": "Кнопка",
                "Оформление": {
                  "ЦветФона": "primary"
                },
                "ПутьКДанным": "КлючКHashMap-е-НазваниеУсловноеДляПримера",
                "Действие": {
                  "Команда": "GetAction",
                  "ПараметрыДействия": {
                    
                  },
                  "ПередаватьКонтекст": [
                    "КлючКHashMap-е-НазваниеУсловноеДляПримера"          
                  ]
                }
              }
            ],
            "Данные": {
              "КлючКHashMap-е-НазваниеУсловноеДляПримера": "Какое-то-значение"    
            }
          }


      1. Vah-tang
        26.12.2024 07:54

        Импортозамещенный Json - ах, звучит как песня !


  1. andyblaster
    26.12.2024 07:54

    Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.

    Архитектура решения воспроизводит 1С подходы. Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга? Или это больше поверхностная копия на самостоятельном размышлении и наблюдении? Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы. Вы до этих файлов тоже добрались, например?

    Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора? Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?

    Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.

    Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы? Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему? Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям? Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?


    1. varsa Автор
      26.12.2024 07:54

      Спасибо за вопросы! Постараюсь ответить подробно.

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

      В реализацию веб-клиента мы не погружались, даже реверс-инжиниринга не было. Мы посмотрели, что он может, и поняли, что нам «так не годится». Причина проста: веб-клиент 1С привязан к 1С на бэкенде. А у нас мало того, что бэкендов несколько, так они еще и не все на 1С.

      Первый «подход к штанге» — попытка ускорить верстку форм на основе «толстого» платформенного клиента. Бэкендеры написали кусочек кода на 1С, который который обходил форму 1С и выгружал в JSON. А так как в 1С почти все термины на русском («Кнопка», «ПолеВвода», «ЦветФона», «Оформление», «ГруппировкаПоГоризонталиЕслиВозможно»), то и не стали изобретать маппинга с русского на английский. Сэкономили массу времени. Да и сейчас экономим.

      Мы довольно быстро ушли от варианта «а давайте дальше использовать платформенный 1С как инструмент разработки форм и переносить его фичи». Когда интерфейс переехал в браузер, появилась масса хотелок, которые 1С реализовать не мог.

      Итог: Атом.Форм — это полностью самостоятельный продукт, а не копия веб-клиента 1С. Названия некоторых базовых элементов и свойств остались из 1С как реверанс в сторону бэкенд-разработчиков.

      Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы.
      Вы до этих файлов тоже добрались, например?

      Не добрались, да и не нужно было.

      Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора?

      Да, поначалу это выглядело необычно и даже непривычно. Особенно для тех, кто работает на Java или C++. Мы даже сделали DTO и были готовы все попереводить (например, Button вместо «Кнопка»). Но к нашему большому удивлению бекендерам стало проще ставить задачи «Добавить в ТаблицуФормы свойство ЦветФонаЗаголовкаКолонки». Собственно это вся постановка, лакончиная и самодостаточная.

      Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?

      На этапе поиска решения пробовали разные форматы: от QML до YAML. Вкратце — не прижилось. Но JSON оказался оптимальным для браузеров, а к структуре и названиям быстро привыкли.

      Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.

      Рассматривали, но победил Vue. Тут и исторические причины, и то что разработчиков на Vue подобрать проще. Сейчас, когда фронт полностью отделен от бэкенда, мы вольны выбирать любую реализацию — хоть ReactJS, хоть Flutter, хоть собственный АтомJS фреймворк.

      Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы?
      Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему?
      Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям?

      Бекенду необходимо реализовать обработчик для событий которые считаются «бекендными». Например, обрабатывать изменение ширины колонки или ее перемещение мышью не нужно. Но если прилетит запрос «СохранитьНастройкиТаблицы» — такой метод бэкенду придется написать.

      Кроме того, функциональные действия вроде заполнения выпадающих списков данными — это тоже задача бэкенда. У 1С для таких целей есть несколько реализаций прослоек.

      Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?

      И такой вариант есть, с него как я выше написал начинали. Для каких-то форм он годится. Со временем стало понятно что возможности в браузере гораздо шире, чем у «нативного» конструктора 1С. Со временем мы это ощутили и переключились на новый подход.


      1. andyblaster
        26.12.2024 07:54

        Спасибо за исчерпывающий ответ! Стало более понятно.

        Буду с нетерпением ожидать опенсорс/лайт версии продукта, подкрепиться иллюстрациями с документацией и задействовать в корпоративных проектах.


  1. OksikOneC
    26.12.2024 07:54

    Спасибо за статью! Возник вопрос, вы описали следующее:

    "в 1С, например, есть свой инструмент по вёрстке клиентской формы."

    И далее у вас идет скриншот платформенного редактора формы. Далее вы пишите

    Но 1С всем клиентам не поставишь, это практически невыполнимо.

    Думаю, под "не поставишь", Вы имелли виду "это слишком дорого в деньгах"? Ставить веб-клиент не нужно, Вам это и так известно.

    Но более всего интересно, почему Вы не рассматривали технологию 1С Элемент, которая как раз и предназдачена для описанного в статье кейса, как по самой технологии, так и по политике лицензирования?


    1. varsa Автор
      26.12.2024 07:54

      "в 1С, например, есть свой инструмент по вёрстке клиентской формы."
      И далее у вас идет скриншот платформенного редактора формы.

      Все верно, платформенного редактора формы 1С.

      Но 1С всем клиентам не поставишь, это практически невыполнимо.
      Думаю, под "не поставишь", Вы имелли виду "это слишком дорого в деньгах"? Ставить веб-клиент не нужно, Вам это и так известно.

      Да конечно, в курсе что ставить вебклиент не нужно. Имелось ввиду «платформенного клиента 1С всем не поставишь».

      А вебклиент 1С нам не подошел потому что не все бэкенды на 1С. Насколько я знаю, вебклиент 1С нельзя скачать, установить и запустить отдельно и в самостоятельном докер-контейнере без платформы 1С. Могу быть не прав, не большой специалист в 1С.

      Но более всего интересно, почему Вы не рассматривали технологию 1С Элемент, которая как раз и предназдачена для описанного в статье кейса, как по самой технологии, так и по политике лицензирования?

      Да, спасибо за вопрос, он ожидаемый.

      Когда мы начинали проект и уже даже сделали MVP в 2021 году, 1С:Элемент был только анонсирован. В публичный доступ его выложили чуть ли не в декабре 2024 года. Мы на тот момент уже второй год как были в продуктиве.

      Сказать по версиям 1С:Платформы мы не можем, нам нужны сертифицированные решения по понятным причинам. Заставить все бэкенды пользоваться 1С:Элемент мы тоже не можем. Атом.Форма это универсальный вебклиент для любого бэкенда на любой технологической платформе.