Разработка мобильного приложения для сравнения цен (Price Comparison)
Агрегатор цен — это прежде всего задача парсинга и синхронизации данных. Мобильное приложение само по себе несложное: список товаров, фильтры, история цен, уведомления. Но вся архитектура завязана на бэкенд, который собирает цены из десятков источников и держит их актуальными. Без этого — просто красивая оболочка без данных.
Как работает агрегация цен
Три источника данных, у каждого свои плюсы и ограничения:
Партнёрские API магазинов. Официальные фиды от Яндекс.Маркета, Google Shopping, Amazon Product Advertising API, партнёрки крупных ритейлеров. Данные актуальные, есть официальный SLA. Минус — охват ограничен аффилированными магазинами.
Scrapers. Для магазинов без API. Тут начинается война с anti-bot защитой: Cloudflare, CAPTCHA, fingerprinting, rate limiting. Playwright/Puppeteer в headless режиме, ротация User-Agent и IP через proxy-пул. Легальность — серая зона, зависит от страны и ToS магазина.
Пользовательский краудсорсинг. Пользователь сканирует штрих-код в магазине и фиксирует цену. Работает в нишах, где официальных данных нет (локальные рынки). Требует верификации: цена от одного пользователя — подозрительно, от трёх разных в течение суток — достоверно.
Сканер штрих-кодов
Основной способ поиска для офлайн-шопинга. На iOS: AVCaptureSession + AVMetadataObjectTypeEAN13Code, EAN8Code, UPCECode, QRCode. Важно добавить haptic feedback при успешном сканировании — UIImpactFeedbackGenerator — пользователь не всегда смотрит на экран.
Поиск по штрих-коду — сначала локальный кеш (LRU-кеш последних N товаров), потом API-запрос. Если товар найден в кеше — результат мгновенный. Это критично: пользователь в магазине стоит у полки и ждёт.
История цен
Каждое изменение цены — отдельная запись PriceHistory с productId, shopId, price, currency, recordedAt. Не перезаписывай текущую цену — только добавляй новую строку. График изменения цены за 30/90/365 дней строится из этой таблицы.
На мобильном клиенте кешируем историческую кривую как компактный бинарный формат (не JSON — JSON раздует трафик). Protocol Buffers или MessagePack для передачи ценовой истории.
Уведомления о снижении цены
PriceAlert — пользователь устанавливает целевую цену на товар. Бэкенд проверяет при каждом обновлении прайса: newPrice <= targetPrice. Доставка через FCM (Android) / APNs (iOS). Важно: уведомление должно приходить быстро — пользователь принимает решение о покупке в моменте. Задержка более 30 минут снижает конверсию.
Структура мобильного приложения
Поиск (текстовый + штрих-код), карточка товара с ценами по магазинам, фильтр по расстоянию (геолокация для поиска ближайших магазинов с нужной ценой), история цен, watchlist с алертами. Offline-first для watchlist — локальный кеш, синк при появлении сети.
Сравнение «корзины»: пользователь набирает несколько товаров, приложение считает, в каком магазине суммарно дешевле. Это требует нормализации единиц измерения (1 кг vs 500 г × 2).
Процесс работы
Главное решение на старте — откуда берём данные о ценах. От этого зависит 60% архитектуры. Если есть партнёрские договорённости с магазинами — задача упрощается. Если нет — закладываем scraping-инфраструктуру. Определяем категории товаров, регион, целевую базу магазинов.
Ориентиры по срокам
Мобильное приложение (без бэкенда) с поиском, карточками, историей цен из готового API — 4–7 недель. Полный продукт с собственным бэкендом сбора цен, алертами и корзинным сравнением — 14–22 недели. Стоимость рассчитывается индивидуально.