torinasakura/japass

just-another-parser-and-syncer-software

japass's Issues

надо будет в следующих итерациях вынести наверх, в отдельный сервис мастер данных

    надо будет в следующих итерациях вынести наверх, в отдельный сервис мастер данных

Originally posted by @TorinAsakura in #29 (comment)

Jobs troubleshooting

Описание бага

Джобы write-all-products и synchronizer ведут себя нестабильно, в ходе работы они падают с ошибками

Ожидаемое поведение

Джобы должны работать стабильно

Материалы

synchronizer - 12 рестартов
write-all-products-job - 410 рестартов

➜  ~ kubectl get pods
NAME                                                   READY   STATUS             RESTARTS   AGE
synchroninzer-service-65b4585976-fhd2x                 2/2     Running            12         5d11h
synchroninzer-writer-service-5944554d4d-txzhp          2/2     Running            0          5d22h
synchronizer-write-all-products-job-7774fb55fc-6httr   1/2     CrashLoopBackOff   410        5d22h
test-synchronizer-write-all-products-job-mprdh         1/2     NotReady           0          33d

Переработать сервис

С чем связан запрос на фичу?

Переработать сервис

Расскажите как вы это себе видите

Synchronizer job:

1. Брать позиции с маркета
2. Брать с каждой артикул. Артикул может быть с префиксом prefix-article, в этом случае просто делать сплит и брать только article, который соответствует артикулу комусе
3. Синкать эти позиции с базой по полям remains и price. Если одно из полей устарело - делать синк с ЯМ

Write all products job:

Работает по-прежнему, просто пишет базу все позиции с комуса с поправкой на то, что сейчас нам не нужно брать detailed информацию о позиции. Возможно придется обновить таблицу в бд

Доп логика при записи товаров

Задача

Преобразовывать цены на товары перед записью на ЯМ

Материалы

(Закупочная стоимость *1.9+105) *1.09 +процент категории за продаж

https://drive.google.com/file/d/1ZggDwtvLDpNWk93EFitLOKxwrWQnBrId/view

WB Integration

С чем связан запрос на фичу?

Интеграция с wildberries

Расскажите как вы это себе видите

Адаптер, как и для yandex-market

Service separation

Разделение сервисов

Планирую сделать 2 сервиса:

• marketplace
• supplier

Supplier

• Отвечает за запись продуктов в базу и синхронизацию остатков

Marketplace

• Будет иметь порты в домене и описанную логику синхронизации продуктов (на основе портов)
• ЯМ, ВБ и прочие маркетплейсы будут в виде адаптеров
• Подразумевается что один инстанс сервиса отвечает за синхронизацию товаров с одним маркетплейсом. То есть для того чтобы одновременно синхронизировать продукты с ЯМ и вайлдбериз нам понадобится поднять 2 инстанса marketplace сервиса
• Чтобы переключать инстансы в marketplace сервисе будет несколько энтрипоинтов: по одному энтрипоинту на маркетплейс. Т.е. yandex-market-service-entrypoint, wildberries-service-entrypoint и т.п.

Shared слой

Так как и marketplace, и supplier сервисы у нас работают с одной и той же сущностью/репозиторием - с продуктами, я планирую вынести ProductsRepositoryImpl, TypeORMEntities и прочее, что касается конфигурации TypeORM в shared слой. Infrastructure слои обоих репозиториев будут просто использовать ProductsRepository из shared слоя, подключение к базе будет одно общее

Пример

Bad products

Задача

Исследовать продукты, которые невозможно выставить на продажу на ЯМ

• Недостающие поля
• Поля, заполненные с ошибкой

Оптимизация запросов на Комус

С чем связан запрос на фичу?

Эндпоинт Комуса отвечает очень долго, поэтому работу с ним необходимо оптимизировать

Расскажите как вы это себе видите

Делать несколько запросов параллельно, это позволить ускорить работу с Комусом примерно в 5 раз (зависит от ограничений Комуса по параллельным запросам)

Сервис synchronizer

С чем связан запрос на фичу?

Сделать сервис synchronizer, отвечающий за синхронизацию товаров от поставщика с товарами на маркетплейсе

Расскажите как вы это себе видите

Документация партнерского API яндекс маркета

Документация API комуса