Как лучше реализовать данную архитектуру?

Question

[Molex20021]

Хочу написать свой агрегатор контента на go. Архитектурная идея состоит в следующем: при запросе к серверу от конкретного пользователя включается python скрипт, который парсит контент из источников и обновляет бд, затем пользователю выдаётся результат в виде обновленного контента.

Так вот, как такое можно реализовать? А именно, как запускать python скрипт при запросе по выдаче контента?

Comments

[uvelichitel]

Запускать python скрипт при помощи cron (или другого диспетчера задач) раз в 10 минут, а не при запросе и пусть себе обновляет бд.
А зачем вообще python? Go тоже прекрасно может парсить контент из источников и обновлять бд. А python может сам отвечать на http запросы. Зачем два языка?

Answer 1

[Ромзес Панагиотис]

Когда пользователь ждет пока агрегатор выполнит свою работу - это нехорошо. Правильнее, чтобы первый захотел некоторый контент и сразу мог получить его, прямиком с БД, а в идеале с кэша частозапрашиваемого контента.
Для этого агрегатору необходимо регулярно выполнять свою работу независимо от посетителей, в фоне. Разумеется, пайплайн агрегатора должен заранее знать откуда заполучать контент или же одноразово получить список источников в начале, пройтись по ним и занести данные в БД. Затем регулярно обновлять с уже известных источников независимо от захода пользователей.

Ну а если в БД пусто и позарез нужно выдать контент, то остается плохой вариант - дать пользователю ждать, пока контент не будет скачан, обработан агрегатором и получен обратно. В данном случае, при попытке получения контента можно выдать сообщение, что мол, "Извините-с-с, заходите чуток позже" или же "Подождите 5 сек, я быстро-быстро". А когда свежий контент уже был обработан, то отправить назад контент по SSE/WebSocket. Или же short polling просто клиент будет периодично выполнять запросы к API с надеждой получить контент.
Вот здесь можно прочесть о способах взаимодействия

Поэтому я вижу такую архитектуру при работе с пользователем:

Client -> API -> cache/DB (read)
             \
              MQ
                 \
               [Aggregator]
                      \
                      DB (write)

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

По мне, так бизнес-логику на Go писать не очень удобно и ее лучше осуществлять на более высокоуровневых языках. Так что в Go я бы реализовывал механизм скачивания контента и извлечения нужных частей, а в Python/Ruby/Perl и т.д. - логику самого агрегатора (смешение, композитинг контента).

Comments

[Molex20021]

Спасибо огромное за развернутый ответ! Так выглядит рациональнее, просто хотелось попрактиковаться в бэке на go и заодно парсинге данных на python. Тогда постараюсь реализовать именно так)