Блог

От backend-архитектуры до интерфейса взгляд изнутри на «Трансфорт»

От архитектуры бэкенда до интерфейса, реагирующего на каждое действие. В статье покажем, что внутри у платформы, через которую ежедневно проходят тысячи логистов и заказчиков. 🛠 Как мы переписали монолит на микросервисы 🧩 Почему фронтенд – это не просто интерфейс, а управляемая система 📉 Как снизили количество багов 📦 Что сделали, чтобы платформа росла без боли
avatar user
Кондратенко Сергей
CIO
8 августа 2025 г.
#Разработка
#Логистика
#Сервисы

В статье “Полный апгрейд “Трансфорт”. Управление логистикой без ограничений” мы рассказали, как перезапуск платформы помог бизнесу выйти на новый уровень, оптимизировать процессы, повысить их качество и обеспечить рост клиентской базы. Но за внешним результатом скрывается кропотливый труд разработчиков и тщательная работа над ошибками предыдущей реализации.

“Трансфорт” – это сложная экосистема для логистики и торгов в сфере перевозок: обработка заказов, управление автопарком, формирование документов, интеграции с внешним ПО, аналитика. Внутри тысячи действий, десятки сценариев и множество ролей. И всё должно работать быстро, стабильно и адаптироваться без боли.

Когда NooSoft взялся за проект, стало очевидно: “косметический ремонт” тут не поможет. Локальные улучшения решали задачи поверхностно, но фундамент требовал полной перестройки.

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

Архитектура: гибкость против хаоса

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

С перезапуском платформа получила прогрессивную микросервисную архитектуру, построенную на Nest.js, и разнесённую по логически изолированным блокам.

Шлюзы:

  • для внешних API и клиентов;
  • для 1С и ERP заказчика.

Сервисы:

  • бизнес-логики;
  • уведомлений;
  • файловый;
  • интеграций.

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

Разработка и развертывание тоже стали легче. Решение обернуто в контейнеры с помощью Docker, теперь можно быстро поднимать стенды, запускать CI/CD и управлять окружением.

В основе платформы:

Backend

  1. Nest.js – фреймворк, построенный на модульной архитектуре и поддерживающий строгую структуру и рост платформы.
  2. PostgreSQL – база данных, оптимально подходящая для сложных, связанных сущностей.
  3. Redis – для хранения временной информации, такой как коды подтверждения или кеш откликов.
  4. NATS – легковесная и высокопроизводительная шина сообщений для взаимодействия между компонентами.
  5. Docker – для контейнеризации и настройки окружений.

Frontend

  1. React 18 – современная библиотека для построения UI с продвинутой управляемостью состоянием.
  2. TypeScript – строгая типизация, упрощающая масштабирование.
  3. Vite – быстрый и лёгкий сборщик.
разработка трансфорт
Технологический стек

Чтобы избежать классической ловушки «всё зависит от всего», мы строго изолировали бизнес-алгоритмы от инфраструктурных компонентов. Каждому модулю дана своя область ответственности и ограниченный API.

Коммуникация внутри приложения проходит через явно определённые интерфейсы и сервисы. Внешние зависимости (например, вызовы к 1С, Автокоду или Dadata) инкапсулированы в отдельные абстрактные слои, что позволяет при необходимости менять реализацию без переписывания бизнес-процессов.

Для обеспечения стабильности при росте нагрузки заложены:

  • расширяемая структура модулей и очередей задач (через Redis);
  • возможность вынесения тяжёлых операций в отдельные worker-процессы;
  • изоляция хранилища сессий и кешей.

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

Backend в деталях

В основе бэка лежит PostgreSQL с классическим подходом к нормализации. Мы отказались от перегруженных сущностей и плотной вложенности в пользу чистых таблиц и чётко структурированных связей между ними. Бизнес-логика, связанная с организациями, заказами, транспортом, пользователями и откликами, разделена на независимые домены с понятными контрактами взаимодействия.

Для поддержания целостности данных и согласованности связей используется комбинация ограничений на уровне БД и контроля через прикладной слой. Это помогает избегать “плавающих” записей и конфликтов при обновлениях.

разработка веб сервисов
Фрагмент проработки связей данных

Особое внимание уделено адресной модели: адреса и точки маршрута вынесены в отдельные таблицы с географическими координатами, что в перспективе позволит подключить геоаналитику и более точные расчёты расстояний, траекторий и зон ответственности.

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

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

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

Значимой частью процесса были ревью и контроль изменений, чтобы убедиться, что параметры перенесены полностью и корректно.

Работа с транзакциями и обработкой ошибок

В новой платформе ключевые операции – создание и обновление заказов, откликов, профилей и документов – выполняются в рамках явных транзакций с ручным контролем откатов. Это гарантирует целостность и предотвращает появление частично применённых изменений при багах.

Для обработки уязвимостей реализован централизованный middleware-слой, который обеспечивает:

  • типизацию всех исключений для удобства отладки и унификации реакции на них;
  • преобразование сообщений в формат, понятный frontend-команде и доступный для вывода в интерфейсе;
  • логирование через вызовы toast-уведомлений, которые информируют пользователя о возникших проблемах;
  • одновременное консольное логирование для разработчиков, что помогает быстро находить и устранять неисправности.

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

Благодаря архитектуре с разделением логики по слоям, формам теперь не требуется повторно валидировать все данные на сервере. Обработка ошибок осуществляется локально, отображение предупреждений и подсказок – в реальном времени, а в сложных сценариях – через модальные окна и toast-уведомления (react-toastify).

Также реализована система fallback'ов и проверок на случай потери связи с API. Например, если сервер не отвечает, интерфейс показывает понятные статусы вместо зависших форм.

Интеграции и работа с внешними сервисами

Платформа “Трансфорт” изначально проектировалась как система, тесно взаимодействующая с внешними сервисами и корпоративными продуктами. Старая реализация интеграций была нестабильной, отсутствовали: стандарты API, централизованное логирование и предсказуемая схема обработки сбоев. Это приводило к рассинхронизации и потере откликов.

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

Коммуникация с внешними модулями осуществляется по HTTP через REST API. Для каждой интеграции выделен отдельный провайдер, реализующий унифицированный интерфейс и абстрагированный от бизнес-логики. Это позволяет локализовать изменения в API партнёров и не затрагивать внутренние процессы платформы.

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

Интеграции


  • Основная интеграция B2B-уровня. Производит передачу заказов, реквизитов организаций, статусов и документации. Реализованы универсальные API-интерфейсы, адаптирующиеся под разные конфигурации 1С.
  • ERP-система заказчика
    Внутренние системы пользователей, откуда в “Трансфорт” поступают заказы. Также с ними синхронизируются документы и статусы. Интеграция учитывает бизнес-логику платформы, включая автоматические комиссии, фильтрацию по типу транспортного средства и ограничениям по маршрутам.
  • Dadata
    Применяется для автозаполнения и валидации данных: ИНН, адресов, информации об организациях. Подключение позволило:
    – повысить точность пользовательского ввода;
    – сократить количество ошибок при заполнении форм;
    – ускорить регистрацию и оформление документов.
    Обёртка над API Dadata гибко управляет таймаутами и подсказками.
  • Автокод
    Используется для получения информации о транспортных средствах при регистрации или обновлении сведений.
разработка кейса проекта
Взаимодействие с интегрированными сервисами

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

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

Frontend: логика, а не просто интерфейс

Редизайн платформы «Трансфорт» начался с полной переоценки интерфейсной логики. Мы отказались от устаревших 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 разворачивались как отдельные контейнеры. Применяли:

  1. Docker – для унификации окружений.
  2. Vite – как сборщик на клиентской части.
  3. NestJS – на серверной части, с поддержкой hot-reload в dev-окружении.
  4. PostgreSQL и Redis – как основные инфраструктурные сервисы.

Перед релизом функциональности она тестировалась вручную внутри команды и выносилась в staging-среду. Этап позволял оценить реальное поведение форм, авторизации, откликов, сценариев взаимодействия с внешними API, прежде чем выкатывать в продакшн.

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

Метрики и рефлексия

В результате комплексного апгрейда «Трансфорт» удалось достичь значительных улучшений в технических показателях и в качестве разработки и поддержки.

Улучшение производительности API

Среднее время ответа серверных API сократилось примерно на 70% благодаря переходу на современный стек и оптимизации архитектуры. Использование Nest.js и эффективное управление состоянием через Redux Toolkit минимизировало задержки при обработке запросов. Разработчики отмечают явное ускорение отклика системы, что повышает удобство работы пользователей и общую отзывчивость платформы.

Снижение числа багов в продакшн-среде

Перевод проекта с JavaScript на TypeScript с жесткой типизацией помог уменьшить количество ошибок, возникающих на продакшене. Строгая типизация на уровне кода и централизованное реализация стейт-менеджмента через Redux Toolkit повысили стабильность, а современный процесс сборки и линтинг кода способствовали раннему выявлению и исправлению багов. В совокупности эти меры привели к заметному снижению инцидентов в работе платформы.

Готовность к расширению

Выбранная архитектура – модульный монолит с четким разделением на слои – снизила сложность интеграции новых блоков и сервисов. Благодаря модульной структуре и компонентному подходу разработчики смогли быстро масштабировать платформу под растущие бизнес-требования, не рискуя стабильностью. Уже реализованная интеграция с 1С, ERP системами заказчика, Dadata, Автокод служит подтверждением гибкости архитектуры.

Упрощение разработки новых возможностей

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

трансфорт новый
Итоги

Заключительный штрих 

Теперь, прочитав обе статьи, вы видите полную картину: как мы не просто обновили платформу, а построили надёжный и гибкий фундамент для роста бизнеса. Это история о том, как технологии и продуманный подход создают инструменты, которые работают на результат и открывают новые возможности.

Контакты

свяжитесь с нами, мы это любим!
Скачать презентацию
Оставьте заявку