Фронт без бэка: как мы сумели собрать тысячу форм в одну систему и не потерять рассудок

от автора

Когда три года назад в июле к нам пришли с просьбой сделать фронтенд для маленькой системы документооборота, мы оценили задачу в полгода… ТЗ принесли на создание более 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 цифры обрезались, не влезали, пары нулей в конце не видно, и надо было сделать корректное визуальное отображение этого длинного числа. Когда мы починили, оно везде стало хорошо отображаться сразу у всех.

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

А что дальше

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

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/869590/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *