Python3.12 + Сервис по работе с авито
Сервис:
Копирую ссылку с авито, циан, яндекс недвижимость - передаю в сервис
После сервис предоставляет мне api
Он мне предоставляет информацию:
1. Снято с публикации
2. Цена
реализация -
пускай будет python3.12 и выше, апиха на fastapi + sqlalchemy + pydantic,
Db - postgresql/mysql
Принципиальная схема работы:
1)
POST /v1/urls добавить url для периодического чека
{"url": "htt...://av.to.ru/..."}
- принимает url определенных форматов (нужны примеры)
- распознает какой источник данных (авито циан и тп)
- кладет запись в БД вида
URL
id - uuid
url - url как есть в определенном формате(для каждого типа свой)
source_type авито циан и тп
last_check_ts время последнего чека (nullable)
is_publicated опубликовано или снять с публикации(nullable)
price цена (nullable)
GET /v1/urls/<uid> получить вышеуказанный объект по uuid
GET /v1/urls/?url=<url> получить вышеуказанный объект по url
POST /v1/urls/?url=<url> получить вышеуказанный объект по url (c обновлением данных с сайта источника)
POST /v1/urls/<uid>. получить вышеуказанный объект по url (c обновлением данных с сайта источника)
DELETE /v1/urls/<uuid> удаляет url из бд
2) должно быть периодическое фоновое задание - реализовано может быть по средством cron , или других механизмов - можно обсудить
должно работать так: идем по всем url из бд где обновления не было никогда либо было раньше чем сутки назад, идет на сайт источника и
обноаляет данные в БД.
Вопрос- ответ
1. Какое примерное количество URL'ов планируется обрабатывать? Это поможет определить необходимую производительность системы и выбрать оптимальную стратегию масштабирования.
2. Есть ли требования к времени отклика API, особенно для методов с обновлением данных?
3. Планируется ли интеграция с другими сервисами помимо Авито, Циан и Яндекс Недвижимости? Если да, то с какими?
4. Какие меры безопасности нужно предусмотреть для API? Например, аутентификация, ограничение запросов и т.д.
5. Будем ли использовать proxy? Возможно уже куплен пакет, если нет потребуются мобильные на время разработки.
6. Какие требования к логированию и мониторингу системы?
7. Планируется ли разработка клиентской части или только API?
8. Механизм обработки ошибок при парсинге сайтов, так как структура страниц может меняться, и нужно предусмотреть механизмы обнаружения и обработки таких изменений.
1) ~ 0.1K - 10K
2) требований нет - но порядка 30ms в 95песентиле на GET будем считать норм, при нагрузке 100rps
3) система должна быть толерантна к добавлению очередного провайдера, провайдер будет конфигурацией системы, грубо говоря провайдер это
некий паттерн url-a + некий обработчик способный по данному урлу сходить
4) на данном этапе это внутренний сервис - аутентификация может отсутствовать
5) прокси должно быть конфигарацией провайдера - пока никаких пакетов нет - в их необходимость в тч для разработки нужно убедиться
6) пока требований нет - пускай будет логгирование в файл на диск.
7) апи простое клиент не потребуется
8) ошибки обработки пока будем писать в тот же лог что в пункте 6) в особой обработке данных кейсов смысла пока не видно
Копирую ссылку с авито, циан, яндекс недвижимость - передаю в сервис
После сервис предоставляет мне api
Он мне предоставляет информацию:
1. Снято с публикации
2. Цена
реализация -
пускай будет python3.12 и выше, апиха на fastapi + sqlalchemy + pydantic,
Db - postgresql/mysql
Принципиальная схема работы:
1)
POST /v1/urls добавить url для периодического чека
{"url": "htt...://av.to.ru/..."}
- принимает url определенных форматов (нужны примеры)
- распознает какой источник данных (авито циан и тп)
- кладет запись в БД вида
URL
id - uuid
url - url как есть в определенном формате(для каждого типа свой)
source_type авито циан и тп
last_check_ts время последнего чека (nullable)
is_publicated опубликовано или снять с публикации(nullable)
price цена (nullable)
GET /v1/urls/<uid> получить вышеуказанный объект по uuid
GET /v1/urls/?url=<url> получить вышеуказанный объект по url
POST /v1/urls/?url=<url> получить вышеуказанный объект по url (c обновлением данных с сайта источника)
POST /v1/urls/<uid>. получить вышеуказанный объект по url (c обновлением данных с сайта источника)
DELETE /v1/urls/<uuid> удаляет url из бд
2) должно быть периодическое фоновое задание - реализовано может быть по средством cron , или других механизмов - можно обсудить
должно работать так: идем по всем url из бд где обновления не было никогда либо было раньше чем сутки назад, идет на сайт источника и
обноаляет данные в БД.
Вопрос- ответ
1. Какое примерное количество URL'ов планируется обрабатывать? Это поможет определить необходимую производительность системы и выбрать оптимальную стратегию масштабирования.
2. Есть ли требования к времени отклика API, особенно для методов с обновлением данных?
3. Планируется ли интеграция с другими сервисами помимо Авито, Циан и Яндекс Недвижимости? Если да, то с какими?
4. Какие меры безопасности нужно предусмотреть для API? Например, аутентификация, ограничение запросов и т.д.
5. Будем ли использовать proxy? Возможно уже куплен пакет, если нет потребуются мобильные на время разработки.
6. Какие требования к логированию и мониторингу системы?
7. Планируется ли разработка клиентской части или только API?
8. Механизм обработки ошибок при парсинге сайтов, так как структура страниц может меняться, и нужно предусмотреть механизмы обнаружения и обработки таких изменений.
1) ~ 0.1K - 10K
2) требований нет - но порядка 30ms в 95песентиле на GET будем считать норм, при нагрузке 100rps
3) система должна быть толерантна к добавлению очередного провайдера, провайдер будет конфигурацией системы, грубо говоря провайдер это
некий паттерн url-a + некий обработчик способный по данному урлу сходить
4) на данном этапе это внутренний сервис - аутентификация может отсутствовать
5) прокси должно быть конфигарацией провайдера - пока никаких пакетов нет - в их необходимость в тч для разработки нужно убедиться
6) пока требований нет - пускай будет логгирование в файл на диск.
7) апи простое клиент не потребуется
8) ошибки обработки пока будем писать в тот же лог что в пункте 6) в особой обработке данных кейсов смысла пока не видно