Какую архитектура и технологии выбрать для учебного проекта на Python?

Question

[bopox88]

Изучаю Python, и нужна практика, поэтому решил сделать учебный/pet-проект. Задачи проекта:

• получение от пользователя наименования товара;
  
• предварительный парсинг магазина с целью найти товар;
  
• направление пользователю ссылки на найденный товар для подтверждения;
  
• после подтверждения постановка товара на ежедневный парсинг;
  
• уведомление пользователя об изменении цены на 5%+.
  

Потом список функций можно нарастить, пока хочется реализовать именно этот минимум.

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


Бесспорным слабым местом такого подхода будет парсер, поэтому точно потребуется создание очереди. Для очереди хочется сделать "костыль"/"велосипед", а не использовать готовое решение (учеба же). Потом можно будет прикрутить RabbitMQ. Пока вижу следующие решения:

• реализация очереди на API-сервере. Сервер будет вести очередь парсинга и "пулять" запросы в парсер. После получения ответа удалять задачу из очереди;
  
• реализация очереди на самом парсере. Но для этого, видимо, нужно будет к парсеру прикрутить простенькую БД.
  

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

Answer 1

[Александр Нестеров]

Вообще не очень понятно - каким боком тут затесался django.
По моему, достаточно библиотеки aioscheduler или банального cron`а. Что-то одно из этого будет каждый заданный промежуток времени запускать скрипт парсера, который в свою очередь будет брать данные для парсинга из базы.
А сами данные в базу можно спокойно добавлять и на стороне aiogram.
UPD: Ну и сообщения можно отправлять либо прямо из парсера, но только с помощью api телеги и aiohttp, если запускаете асинхронно.

Comments

[Александр Нестеров]

http-запросы парсера в случае асинхронного запуска так-же стоит выполнять с помощью указанной библиотеки.

[bopox88]

Хочется пощупать REST API, поэтому вот такая городушка получилась. Так-то понятно, что к боту можно прикрутить sqlalchemy, а парсер через хрон дергать.

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

С очередью парсинга тоже не все так просто, так будут задачи с разным приоритетом: для ежедневного парсинга и парсинга для подтверждения товара

[bopox88]

Александр Нестеров, спасибо!

[Алан Гибизов]

bopox88, ОРМ у Django есть, но я потыкался и мне показалось, что с ней можно жить только если в нее погрузиться и не выныривать. Слегка потыкать в нее палочкой не даст понимания, а сил и времени займет уйму. Вообще ОРМы я не понял в том смысле, что в них как-то если два плюс два то вроде да, а чуть глубже - всё становится как-то неочевидно и если ты в ней не живешь, а так, одноразово, то становится проще сделать execute.

[bopox88]

Алан Гибизов, при выборе технологий хочется опираться на некие отраслевые стандарты. Самый доступный для меня способ понять эти стандарты - мониторинг вакансий. Так вот я встретил достаточное количество вакансий, где идёт именно связка django + django rest fw. Полагаю, что в такой свзяке встроенный ORM будет точно не лишним.

Я пробовал Sqlalchemy в качестве ORM для прошлого проекта (телеграм бот). Так вот мне очень понравилось, очень сильно упрощает жизнь, а для сложных запросов всегда есть возможность сделать execute методами ORM. Но полагаю, что для функционала REST API среднего проекта, сложные запросы особо и не нужны.

Хотя, конечно, это все мое представление - человека, не имеющего никакого опыта.

[Алан Гибизов]

bopox88, да я тоже не суперпрофи, так что с вами согласен. Но мне Django так не зашло сразу, что я наверно пристрастен. Надо просто, наверное, вернуться к нему через время…
Удачи!