Ответы пользователя по тегу Проектирование программного обеспечения
  • Как лучше реализовать данную архитектуру?

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

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

    Поэтому я вижу такую архитектуру при работе с пользователем:
    Client -> API -> cache/DB (read)
                 \
                  MQ
                     \
                   [Aggregator]
                          \
                          DB (write)

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

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

    romesses
    @romesses
    Backend инженер
    Обычно пишут API-frontend (его экземпляры), клиентами которого выступают потребители контента. Ну у позади API своя БД и кэширование, если надо.
    Ответ написан
  • Можно ли любое GUI положение сперва реализовать в консольном варианте, а потом уже привязывать к нему GUI?

    romesses
    @romesses
    Backend инженер
    Можно ли любое GUI положение сперва реализовать в консольном варианте, а потом уже привязывать к нему GUI?
    Едва ли. Для простых еще можно, а для сложных, как Excel?
    Начинать нужно с проектирования:
    - расписать какие есть сценарии работы
    - начать собирать макеты интерфейса
    - определить что требуется на входе и на выходе каждого действия
    - декомпозировать на мелкие задачи
    - спроектировать интерфейсы вызовов API
    - разделить их на логические модули - DLL и их аналоги
    - написать заглушку для каждого вызова
    - написать некоторые тесты
    - реализовать интерфейсы поэтапно
    - пробовать на тестовом стенде: можно консольное, а можно и графическое приложение.
    - и из кубиков собирать приложение.
    Ну как-то так.
    Ответ написан
  • Какая инфраструктура должна быть для 24/7 парсера обновляющего БД?

    romesses
    @romesses
    Backend инженер
    Можно построить архитектуру приложений так, что API будет работать преимущественно в режиме чтения с СУБД.
    А другой процесс-воркер будет получать задачи через очередь сообщений и интенсивно писать в СУБД.
    В API вместо блокирующего ответ клиенту парсинга нужно сразу слать задание в очередь сообщений. Тогда соединения не будут удерживаться подолгу, а почти сразу будут закрыты по отправке в очередь.
    Все, что шлется в API для добавления в очередь, можно возвращать ответ 202 (Accepted).
    Как только воркер выполнит задачу, он обновит результат парсинга в БД. А тем временем, при обращении по API информация будет считана с БД без каких-либо блокирующих операций.

    То есть небольшой апгрейд состоит в схеме:
    APIs (write) -> MQ -> Worker(s) -> DB
    APIs (read) <-> DB
    Так легко добавить любой компонент в случае большой нагрузки.

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