Что нового?

В 2024 году вышла в релиз новая версия Offline Trade-In, которая сильно превосходит легаси, которое работало на стеке 2017 года. Это было раньше:

• SSR на стороне Django (Python v3.6)
• jQuery / JS Vanilla / Web API

Краткая история: В 2020 году код фронта (при моем первом знакомстве с ним) представлял собой спагетти-легаси и содержал в себе императивную логику преобразования DOM в зависимости от различных событий (понятие Бизнес Логика в приложении отсутствовало в декларативном виде). Таким образом с 2017 по 2024 велась доработка фич (+ максимально возможный рефакторинг в пользу DX), но все это время требовался новый продукт с более удачным подходом в плане поддержки кода и управлению Бизнес Логикой на уровне менеджмента - именно это и будет составлять основную ценность в будущем. И в 2024, наконец, пришло время переписать старое легаси на современные рельсы (ссылка на демо будет в конце). Чтоб эта информация не потерялась, решил задокументировать текущие подходы и достижения в области решения проблем отладки в числе прочего (это был основной момент, требующий решения, т.к. устранив это, мы стали работать намного эффективнее).

Решённые задачи

1. 🏗️ Монорепа разделена на фронтенд и бэкенд

Сборка партнерской версии клиентского приложения вынесена в отдельный проект с настраиваемыми Environments variables для вариативности инстансов (разработка, стейджинг, продакшен) - теперь исходный код узнает для какого инстанса он собирается, только получив envs при сборке (это было важным для нас в рамках спец. операции под кодовым названием "Соскочить с легаси").

2. 💼 Управление Бизнес Логикой стало прозрачным

Главная особенность текущего проекта (точнее, одного из тех что в работе) заключается в требовании гибкой настройки ветвлений пользовательских сценариев, периодически требующее добавления шагов (в дальнейшем - дискретных состояний Стейт-Машины). Новая реализация позволяет донастраивать различные сценарии поведения веб-приложения и дебажить эти сценарии на разных уровнях (внутренняя бизнес-логика, данные по API, вычисляемые значения на основе вводимых пользователем данных - одним словом, все параметры, влияющие на успешный User Flow). Чего удалось достичь:

• Настраиваемая последовательность шагов на уровне конфига Стейт Менеджера XState. Это важно, т.к. в прошлых версиях проекта, с ростом вариантов ветвлений сценариев, настраивать их было весьма затруднительно (императивный подход к мутации DOM требовал анализа всего кода без возможности декомпозировать его на отдельные подзадачи)
• Появилась гибкая валидация ответов API на уровне СТМ (сценарий не пойдет дальше, если ответ не соответствует валидации, все подобные ошибки теперь можно транслировать в UI с соответствующей формулировкой)
• На всем промежутке времени моей деятельности в компании не было представителя бизнеса, который полностью владел логикой приложения (даже Продукт менеджер - но это не его вина, просто проект очень стар). На мои попытки явным образом получить описание бизнес-логики в виде вопросов "Как оно должно здесь работать?", я получал что-то вроде "Оно же как-то работает, а сейчас требуется внести небольшое изменение" (опять же, ничего страшного, просто наша команда попала в ловушку легаси без доки). Итак, Документация - теперь она есть в виде конфига XState + интерактивной схемы! Теперь любой разработчик будет знать, как оно работает.

3. 📈 Повысилась эффективность отдела IT

Дебаг и отладка теперь не требуют лишних усилий, репорты по возможным ошибкам сами летят в "Телегу"...

• BFF сервисы (немного фулл-стека): Появилась возможность добавить автоматизированные оповещения об ошибках по socket.io (далее некоторые из них улетают в Google Sheets, Telegram и т.д.) по Socket соединению в отдельном потоке Web Worker. Анализ логов теперь также может быть автоматизирован для ретрансляции в чаты в виде задач (возможно даже с указанием исполнителя).
• Добавлена функция "Сообщить об ошибке", позволяющая отправить сообщение от Пользователя и историю его взаимодействия с приложением для анализа Разработчиком

4. 🤝 Кастомизация UI для каждого из партнёров стала гибче

Решены проблемы вариативности дизайна, связанные с тем, что кодовая база собираемого приложения ранее НЕ была разделена на подпроекты - изменения интерфейса (как и бизнес-логики) затрагивали всех пользователей. Не было unit & e2e тестов.

Стек технологий

• Vite / React / Typescript (принято в стек как современный стандарт, когда SSR не требуется)
• XState v4.x (отлично вписался под свои задачи, связанные с ветвлением пользовательских сценариев, 5-я версия на тот момент ещё была не готова к релизам в прод)
• Valtio (минималистичный и гибкий подход к управлению состоянием на базе нативных JS механизмов объекта Proxy)
• Tailwind CSS / Headless UI (ориентированная на утилиты CSS-инфраструктура для быстрого создания современных веб-сайтов, которая позволяет удобно и быстро создавать кастомные компоненты с заданными стандартными параметрами - настройки стилей типовых элеметнов и т.д.)
• CSS modules / SCSS (для компонентов с нестандартной версткой)
• Web Sockets in Web Workers (для отправки логов в отдельном потоке, не нагружая основной поток)