Здравствуйте!
Решил собрать демо проект для портфолио из всего, что знаю.
Скажу сразу, по кускам я и раньше такое собирал и оно работает. Сейчас просто хочу сделать это максимально православно. Суть такая:
1. Парсер запускается по таймеру cron раз в сутки и собирает данные с определенного сайта, скажем ag.ru
2. Собирает в постгрес, в две таблицы с созданием связующей (хочу показать понимание связи М-М)
3. В качестве морды лица джанга + инфинити скролл на js (js не знаю, просто есть у меня готовый шаблонный код) + js-скрипт, который при прокрутке вниз увозит верхнюю менюшку наверх, но при первом же пикселе скрола обратно вверх тут же показывает менюшку (где то видел, понравилось, кто знает, подскажите, как этот трюк на джиесе гуглить)
4. По скроллу вниз (там троттлинг немножко продумать, это понятно) делается запрос в базу посредством DRF, назад DRF возвращает джейсон с 10 позициями из базы.
5. Само собой логгер loguru все ходы записывает
6. Да, в парсере tqdm показывает процесс в консоли
—
Прошу меня понять, возможно что то тут лишнее, но я специально это добавил, потому что в этом демо проекте хочу показать работодателю весь размах крыльев. А так же прошу не предлагать сменить допустим крон на таск селери, если это не критично.
—
А теперь внимание вопросы:
1. В глубине души я чувствую, что очень некрасивая ситуация получается как минимум в моменте чтения/записи в базу, когда парсер добавляет данные в базу, а с другой стороны пользователь(ли) решил полистать мой инфинити скролл. Как это решается на взрослых проектах?
2. Нормально ли вообще писать внешний парсер с запросами на чистом sql, когда у меня под рукой всё равно уже есть джанга и можно сделать парсер командой. Если да, тогда я тем более не понимаю, как будет запускаться команда джанги (парсер) по крону, если уже основное приложение джанги запущено. Или запускать приложение и попутно команду это нормальная практика?
3. Ну и в целом сойдёт ли такая демка для портфолио?

Ну, вообще, бросается в глаза, знаешь, что - привязка у тебя к деталям каким-то. Ну, например, если у тебя сломается СУБД PostgreSQL, то твой проект ляжет надолго. Нужно будет дела делать, а он будет лежать, потому что какая-то часть сломалась, а он весь к ней привязан. Или сломается Django - то же самое будет. И вот у тебя таких привязок очень много. Видимо, ты не знаешь про интерфейсы, про абстракции и тому подобное.

doo
1. Парсер запускается по таймеру cron раз в сутки и собирает данные с определенного сайта

Ну вот рубануло тебе cron, твои действия?

doo
2. Собирает в постгрес, в две таблицы с созданием связующей (хочу показать понимание связи М-М)

Ну вот не ставится там PostgreSQL или она установлена, а прав у тебя на неё нет, твои действия?

doo
делается запрос в базу посредством DRF

Ну вот ты поставил свою программу, запускаешь её, она должна работать, а оно пишет ошибку “не могу выполнить запрос, ошибка 12345”, твои действия?

doo
хочу показать работодателю весь размах крыльев

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

doo
3. Ну и в целом сойдёт ли такая демка для портфолио?

А всё равно твоё портфолио смотреть никто не будет, так как кучу времени надо тратить. Я бы даже запускать не стал это. Не потому что я там вредный какой-то, а потому, что этих портфолий штук пятьдесят лежит прямо сейчас и все надо просмотреть и отметить за один день, потому что завтра ещё штук сто будет таких же. Так что ты не удивляйся, что ты вроде много сделал, посвятил этому время, а никто не реагирует.

py.user.next
обходных вариантов нет.

Я конечно так не деплоил еще, но на сколько я знаю, обходные пути заключаются в дублировании разных частей на разных серверах. База на двух разных, например и джанга на других пяти разных. Парсер с кроном так вообще могут валяться, чёрт с ними, там логи только поглядывать, ибо при первом же поднятии, парсер наверстывает упущенное.

py.user.next
никто не будет смотреть

Это означает сделать попроще или вообще не делать?)

doo
Парсер с кроном так вообще могут валяться

Надо отвязать парсер от крона. Крон должен быть одним из подходящих вариантов в данный момент. Если крон упал, то парсер подключается к другому планировщику.

То же самое с базами данных. Ты легко должен перейти на другую СУБД, если вариант с PostgreSQL не сработал. Есть для этого ORM. Но тут главное суть понимать. Вот ты зависишь от PostgreSQL, а вот ты что-то сделал и всё так же пользуешься PostgreSQL, но уже не зависишь от неё.

doo
Это означает сделать попроще или вообще не делать?)

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

Так что ты должен быть нужен. Когда ты нужен и про тебя знают вообще, тогда тебя передадут куда надо и к тебе начнут ломиться через мессенджеры, через телефон, приходить разные люди, просить помочь. А так ты хоть запишись этих проектов, никто не будет реагировать. Чаще всего наниматели, кто деньги держит, даже не понимают ничего в этом. Ты такой замечательный, а для них, что сложная программа, что абсолютная тупость какая-нибудь, - одно и то же.

py.user.next
даже не понимают ничего в этом

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

py.user.next
Есть для этого ORM

Понял. Для чтения в джанге достаточно поменять настройки драйвера базы, и ОРМ будет работать так же и с другой базой. А вставку из парсера я могу и на SQLAlchemy написать и на чистом SQL синтаксисе, в этом нет проблемы, просто многие в требованиях указывают именно постгрес, я поэтому и хочу показать это.

Меня больше смущает момент единовременного обращения к базе на чтение (пользователь) и на запись(если совпало с моментом парсинга)