В статье “Полный апгрейд “Трансфорт”. Управление логистикой без ограничений” мы рассказали, как перезапуск платформы помог бизнесу выйти на новый уровень, оптимизировать процессы, повысить их качество и обеспечить рост клиентской базы. Но за внешним результатом скрывается кропотливый труд разработчиков и тщательная работа над ошибками предыдущей реализации.
“Трансфорт” – это сложная экосистема для логистики и торгов в сфере перевозок: обработка заказов, управление автопарком, формирование документов, интеграции с внешним ПО, аналитика. Внутри тысячи действий, десятки сценариев и множество ролей. И всё должно работать быстро, стабильно и адаптироваться без боли.
Когда NooSoft взялся за проект, стало очевидно: “косметический ремонт” тут не поможет. Локальные улучшения решали задачи поверхностно, но фундамент требовал полной перестройки.
Перед нами возникла цель создать устойчивую систему, расширяемую, поддерживаемую и готовую к развитию, без страха что-нибудь сломать, с продуманной архитектурой и современным стеком.
Старый «Трансфорт» страдал от монолитной архитектуры с плотной связкой бизнес-логики и низкой масштабируемостью. Новые функции было сложно внедрять, интеграции приводили к ошибкам и несогласованности данных, а производительность оставляла желать лучшего.
С перезапуском платформа получила прогрессивную микросервисную архитектуру, построенную на Nest.js, и разнесённую по логически изолированным блокам.
Шлюзы:
Сервисы:
Каждый из них выполняет ограниченный набор задач, взаимодействуя с другими через шину сообщений NATS. Такой подход повысил отказоустойчивость и масштабируемость, а также упростил команде параллельную работу.
Разработка и развертывание тоже стали легче. Решение обернуто в контейнеры с помощью Docker, теперь можно быстро поднимать стенды, запускать CI/CD и управлять окружением.
В основе платформы:
Backend
Frontend
Чтобы избежать классической ловушки «всё зависит от всего», мы строго изолировали бизнес-алгоритмы от инфраструктурных компонентов. Каждому модулю дана своя область ответственности и ограниченный API.
Коммуникация внутри приложения проходит через явно определённые интерфейсы и сервисы. Внешние зависимости (например, вызовы к 1С, Автокоду или Dadata) инкапсулированы в отдельные абстрактные слои, что позволяет при необходимости менять реализацию без переписывания бизнес-процессов.
Для обеспечения стабильности при росте нагрузки заложены:
В результате получили архитектуру, которая устойчива к росту, легко адаптируется под новые требования, а главное – даёт прогнозируемое поведение в боевых условиях.
В основе бэка лежит PostgreSQL с классическим подходом к нормализации. Мы отказались от перегруженных сущностей и плотной вложенности в пользу чистых таблиц и чётко структурированных связей между ними. Бизнес-логика, связанная с организациями, заказами, транспортом, пользователями и откликами, разделена на независимые домены с понятными контрактами взаимодействия.
Для поддержания целостности данных и согласованности связей используется комбинация ограничений на уровне БД и контроля через прикладной слой. Это помогает избегать “плавающих” записей и конфликтов при обновлениях.
Особое внимание уделено адресной модели: адреса и точки маршрута вынесены в отдельные таблицы с географическими координатами, что в перспективе позволит подключить геоаналитику и более точные расчёты расстояний, траекторий и зон ответственности.
Перенос данных со старой платформы был одной из важных задач при запуске новой версии. Для этого был разработан специализированный скрипт, который извлекает записи из старой базы и последовательно вставляет их в переработанную структуру PostgreSQL.
Алгоритм учитывает особенности актуальных схем: преобразует форматы, нормализует информацию и сопоставляет идентификаторы между системами. При этом реализованы проверки корректности и целостности сведений на каждом этапе.
Миграция проходила в несколько итераций, включая тестовые прогоны, чтобы избежать потери информации и снизить риск ошибок при релизе.
Значимой частью процесса были ревью и контроль изменений, чтобы убедиться, что параметры перенесены полностью и корректно.
В новой платформе ключевые операции – создание и обновление заказов, откликов, профилей и документов – выполняются в рамках явных транзакций с ручным контролем откатов. Это гарантирует целостность и предотвращает появление частично применённых изменений при багах.
Для обработки уязвимостей реализован централизованный middleware-слой, который обеспечивает:
Такой подход поддерживает предсказуемое поведение при возникновении неполадок, улучшает юзер-опыт и облегчает сопровождение кода.
Благодаря архитектуре с разделением логики по слоям, формам теперь не требуется повторно валидировать все данные на сервере. Обработка ошибок осуществляется локально, отображение предупреждений и подсказок – в реальном времени, а в сложных сценариях – через модальные окна и toast-уведомления (react-toastify).
Также реализована система fallback'ов и проверок на случай потери связи с API. Например, если сервер не отвечает, интерфейс показывает понятные статусы вместо зависших форм.
Платформа “Трансфорт” изначально проектировалась как система, тесно взаимодействующая с внешними сервисами и корпоративными продуктами. Старая реализация интеграций была нестабильной, отсутствовали: стандарты API, централизованное логирование и предсказуемая схема обработки сбоев. Это приводило к рассинхронизации и потере откликов.
В новой версии архитектура интеграций была выстроена с нуля – с приоритетом на изолированность, расширяемость и устойчивость к неисправностям.
Коммуникация с внешними модулями осуществляется по HTTP через REST API. Для каждой интеграции выделен отдельный провайдер, реализующий унифицированный интерфейс и абстрагированный от бизнес-логики. Это позволяет локализовать изменения в API партнёров и не затрагивать внутренние процессы платформы.
Каждый внешний ресурс работает через собственный интеграционный микросервис, взаимодействующий с модулями по протоколам событий и REST-запросам.
Интеграции
Обработка ошибок в интеграционных сервисах реализована через консольное логирование и базовые механизмы уведомлений. Основной мониторинг состояния осуществляется с помощью внешних инструментов.
Каждая интеграция изолирована, что позволяет в случае обновления внешнего API менять только её провайдера без влияния на остальную часть.
Редизайн платформы «Трансфорт» начался с полной переоценки интерфейсной логики. Мы отказались от устаревших UI-библиотек и перешли на современный технологический стек: React 18, TypeScript, Vite и ряд специализированных решений для визуальных компонентов и построения адаптивных систем, чувствительных к данным и контексту.
Одним из первых принципиальных изменений стала реактивная валидация форм. В старой версии контроль корректности запускался только при отправке формы, что тормозило UX и создавало дополнительную нагрузку на пользователя. Сейчас каждый ввод проверяется на лету, мгновенно возвращая обратную связь. Алгоритм реализован на базе react-hook-form с подключением таких библиотек, как react-imask для масок, libphonenumber-js и react-international-phone для поддержки телефонных номеров в международных форматах.
Мы внедрили кастомные валидаторы с внешними зависимостями. Например, email проверяется через сторонний API, который определяет статус и роль профиля. Поскольку большинство форм работают в режиме onChange, нам пришлось тонко настраивать логику срабатывания useFormContext, кастомных useWatch, контролировать порядок рендеров и ограничивать лишние вызовы.
На этом уровне появляются задачи, которые не решаются средствами обычной валидации. Команда столкнулась с необходимостью реализации сложных, управляемых форм с динамическим поведением. Например, форма регистрации модифицируется под заполненный email: пока человек вводит адрес, происходит фоновый запрос на сервер, который возвращает статус аккаунта. В зависимости от ответа (новый, уже зарегистрированный или неподтверждённый пользователь) перестраиваются поля, появляются другие действия, варьируется механика кнопок. Это не банальная визуальная адаптация, а полноценная реакция на бизнес-состояние. Логика реализована через Redux Toolkit и useEffect с множеством условий и оптимизацией сетевых запросов, чтобы не перегружать интерфейс.
Для сохранения стабильности всей архитектуры мы переосмыслили структуру визуального слоя. Компоненты теперь разнесены по функциональным уровням: components, modules, shared, pages, types. Что дало возможность масштабировать проект без нарушения текущих сценариев, переиспользовать блоки, избегать дублирования и быстро подключать новые модули.
Одним из ключевых кейсов, где сошлись UX, логика и технические ограничения, стала форма создания заказа. Её структура меняется в зависимости от выбранного контекста, файлы загружаются через react-dropzone, адреса проверяются и подсказываются Dadata, а вся валидация – фоновая, без остановки пользовательского потока. Это позволило сделать интерфейс по-настоящему отзывчивым.
В то же время фронтенд-разработчики упростили то, что раньше казалось сложным. Исторически поиск заказов был разбит на три разные страницы. Сейчас всё объединено в одну таблицу с фильтрацией – тип перевозки стал всего лишь параметром, а не отдельной логикой. Мы отказались от вложенных маршрутов, сократили количество состояний и страниц, а благодаря предзагрузке через RTK Query ускорили вывод контента и избавились от лишних переключений.
В итоге мы пришли к интерфейсу, который работает быстро и стабильно. Он не мешает пользователю, а помогает за счёт прозрачной логики, четкой архитектуры и гибкого реагирования на данные. Такой подход стал возможен в результате системной работы с фронтендом как с полноценной предметной моделью, а не просто оболочкой.
В то время как продолжалось эксплуатация предыдущей версии «Трансфорта», создавалась новая. Это требовало точности на каждом этапе – от коммита до продакшн-деплоя. Платформа писалась фактически с нуля, при этом нельзя было допустить остановки бизнес-процессов пользователей.
Разработка велась с использованием feature-бранчей и pull request'ов. Каждый функциональный модуль или компонент реализовывался в изолированной ветке. Это позволяло избежать конфликтов и параллельно вести работу над разными участками решения.
Все алгоритмы заранее анализировались и только после выстраивания четкой логики переходили к их техническому исполнению.
Особое внимание уделялось читаемости кода и единообразию – использовался линтинг, строгая типизация и форматирование через eslint, что минимизировало расхождения в стилях между разработчиками.
Для сборки задействовали современный инструмент Vite, который значительно ускорил dev-сборку и улучшил DX. Автоматизированный процесс деплоя позволял быстро проверять изменения в изолированной среде без влияния на других пользователей.
Frontend и backend разворачивались как отдельные контейнеры. Применяли:
Перед релизом функциональности она тестировалась вручную внутри команды и выносилась в staging-среду. Этап позволял оценить реальное поведение форм, авторизации, откликов, сценариев взаимодействия с внешними API, прежде чем выкатывать в продакшн.
Часть компонентов реализовывались как повторно используемые блоки с минимальной связностью, что упрощало их тестирование. Даже при больших изменениях это способствовало проведению быстрых регрессионных проверок.
В результате комплексного апгрейда «Трансфорт» удалось достичь значительных улучшений в технических показателях и в качестве разработки и поддержки.
Среднее время ответа серверных API сократилось примерно на 70% благодаря переходу на современный стек и оптимизации архитектуры. Использование Nest.js и эффективное управление состоянием через Redux Toolkit минимизировало задержки при обработке запросов. Разработчики отмечают явное ускорение отклика системы, что повышает удобство работы пользователей и общую отзывчивость платформы.
Перевод проекта с JavaScript на TypeScript с жесткой типизацией помог уменьшить количество ошибок, возникающих на продакшене. Строгая типизация на уровне кода и централизованное реализация стейт-менеджмента через Redux Toolkit повысили стабильность, а современный процесс сборки и линтинг кода способствовали раннему выявлению и исправлению багов. В совокупности эти меры привели к заметному снижению инцидентов в работе платформы.
Выбранная архитектура – модульный монолит с четким разделением на слои – снизила сложность интеграции новых блоков и сервисов. Благодаря модульной структуре и компонентному подходу разработчики смогли быстро масштабировать платформу под растущие бизнес-требования, не рискуя стабильностью. Уже реализованная интеграция с 1С, ERP системами заказчика, Dadata, Автокод служит подтверждением гибкости архитектуры.
Архитектурные решения и использование современных паттернов сделали добавление новых функций более предсказуемыми и управляемыми. Разделение бизнес-логики, инфраструктуры и пользовательского интерфейса минимизирует влияние изменений на существующий код. Это сокращает время на разработку и тестирование, ускоряя выход релизов и улучшая качество продукта.
Теперь, прочитав обе статьи, вы видите полную картину: как мы не просто обновили платформу, а построили надёжный и гибкий фундамент для роста бизнеса. Это история о том, как технологии и продуманный подход создают инструменты, которые работают на результат и открывают новые возможности.