Стабильность в кармане

Ключевая техническая особенность ecom-инструментов Novex — мобильное приложение работает на общей бэк-части с сайтом и использует единые данные по товарам, остаткам, заказам и пользователям. Об этом более подробно мы рассказали в кейсе «Точка сборки онлайн-ритейла ↗: Поддержка и развитие сложной ecom-платформы на PHP, Nuxt и Flutter».

Общая бэк-часть даёт преимущества:

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

5 человек из команды NAN обеспечивают полный цикл поддержки и развития приложения Novex: от аналитики и проектирования до реализации, тестирования и поддержки

Flutter Developer • DevOps • System Analyst  • QA Engineer • UX/UI Designer • Project manager

Со стороны клиента — внутренняя IT-команда и стейкхолдеры.

Стабильность и производительность

Это стало первым приоритетом: мобильное приложение должно работать предсказуемо при росте нагрузки и активном использовании каталога.

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

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

Параллельно была выявлена и устранена причина крашей приложения, связанная с утечками памяти на фронтенде (некорректная работа EventBus и IntersectionObserver). Подробнее мы рассказывали об этом здесь ↗.

В результате проведённых работ:

• повысилась скорость работы интерфейса;
• исчезли задержки при загрузке каталога;
• улучшилась стабильность приложения;
• был значительно улучшен пользовательский опыт при работе с большим ассортиментом.

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

Настройка CI/CD*

Когда мы зашли на проект, вместе с кодовой базой нам досталась и настроенная ранее CI/CD-схема. Формально она позволяла собирать и выкатывать релизы через скрипты, но была сильно завязана на прежнюю инфраструктуру и процессы. В текущем контуре часть сценариев не работала корректно, а сама схема оказалась избыточно сложной.

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

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

*CI/CD (Continuous Integration / Continuous Delivery) — это практика автоматизации сборки и публикации релизов, которая позволяет ускорять обновления и снижать количество ошибок при выкладке.

Поиск и навигация по ассортименту

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

В мобильное приложение был интегрирован сервис SearchBooster через API, так как SearchBooster не предоставляет готовый поисковый виджет для Flutter. 

Цель разработки — предоставить пользователям сайта и мобильного приложения более качественный поиск и удобный интерфейс, а также начать собирать данные для анализа и улучшения поиска.

 Реализованы:

• текстовый поиск;
• поиск по изображению;
• аудиопоиск;
• поиск по штрих-коду;
• описание запросов к API и правил обработки ответов для мобильного приложения;
• описание интерфейса поиска в мобильном приложении.

Интерфейс подсказок содержит несколько типов подсказок в окне поиска: история поиска пользователя, подсказки по началу ввода, категории, бренды, товары.

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

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

Карточка товара

Карточка товара — ключевая точка принятия решения.
Мы пересобрали её структуру, убрав перегруженность и лишние визуальные блоки. Вместо табов использовали раскрывающиеся секции: описание и характеристики открываются по запросу пользователя, не перегружая экран.

Это снизило когнитивную нагрузку и сделало сценарий выбора товара более понятным и быстрым.

Наличие и способы получения

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

Мы расширили и переосмыслили логику работы с наличием:

• добавили градации остатков (много / средне / мало);
• внедрили расширенные статусы доступности:

• товар в наличии;

• товар доступен в выбранном пункте самовывоза или для доставки;
• товар под заказ / товар в наличии в другом пункте самовывоза;
• товар закончился (доступен самовывоз);
• товар закончился (доставка недоступна);

• вывели выбор способа получения и магазина в каталог, карточку товара и шапку приложения;
• изменили сортировку товаров с учётом доступности.

Для внедрения новой логики:

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

На детальной странице появился блок «Наличие товара», который включает:

• выбранный способ доставки;
• уровень остатков (мало / средне / много);
• возможность изменить способ доставки;
• данные о доступности товара в других филиалах.
  
  

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

Интеграция пунктов выдачи СДЭК

Выполнено:

• доработка экрана оформления заказа для выбора пунктов выдачи СДЭК;
• внедрение логики выбора ПВЗ СДЭК в способ доставки «Самовывоз» – в итоге ПВЗ СДЭК доступны и в способе доставки “Доставка”, и в способе доставки “Самовывоз”;
• в функционале выбора ПВЗ сделали табы для фильтрации типов пунктов выдачи, добавили метки «СДЭК» у соответствующих пунктов в списке, добавили маркер на карте, также добавили отображение стоимости доставки «от» для пунктов СДЭК, отображение возможности бесплатной доставки;
• фильтрация типов ПВЗ;
• отображение стоимости доставки и условий бесплатной доставки,

• корректная работа сценариев самовывоза и доставки.

Основная сложность заключалась не во фронт-части, а в согласовании логики на бэкенде, чтобы все сценарии выбора работали корректно и стабильно.

Мобильное e-commerce-приложение при большом ассортименте и высокой нагрузке — это не набор экранов, а критически важный бизнес-инструмент.
В этом проекте мы сосредоточились на главном: стабильности, предсказуемости и управляемом развитии продукта, где каждое изменение усиливает систему, а не создаёт новые риски.