# Background Processing Проблема с которой мы переодически сталкиваемся на многих проектах это необходимость выполнять задачи: * по таймеру (cron like) * в режиме пакетной обработки (batch jobs) * в фоне (background jobs) * в порядке очереди (queued jobs) и т.д. В зависимости от архитектуры нашего проекта мы обычно добавляем нужную библиотеку для работы с Jobs: * Java - Spring Batch * Ruby - Sidekiq * Python - rq, etc * NodeJS - BullMQ и многие другие. И в большинстве случаев этого больше чем достаточно скажет большинство и я с ним полностью согласен. Но когда у нас не монолит - тут мы задумываемся о том, чтобы наши задачи были запущены неким стороним сервисом. И тут привет сложность, мы начинаем себе задавать следующие вопросы: * Как работать с теми же моделями и сервисами что и в остальных сервисах приложения? * Как шарить конфигурацию в случае необходимости? * Как организовать такой код в проекте? и многое другое В нескольких проектах я видел следующий подход, который мне кажеться решает данные проблемы. Типично для этих проектов мы имеем следующую структуру (см. рисунок ниже) ![](https://621469499-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Lk33ExZ9AulnEh_PKUM%2Fuploads%2F45ILuJe4ANol2xdgYKjE%2Fapi-worker-over-queue.drawio.png?alt=media\&token=880e5fb8-d861-4837-b975-8dcd865ff148) Что мы тут видим: 1. API в процессе работы генерирует некие jobs 2. Jobs попадают в очередь 3. Workers подбирают Jobs **Важно: API & Workers это один репозиторий и один код** Как же мы знаем когда нам нужен API, а когда Worker код? Ответ довольно простой, и лежит в том, что мы можем создать разные настройки для запуска: **API**: node server.js -> который запускает ваш сервер **Worker**: node worker.js -> который запускает нужный вам воркер Дальше можно усложнять, например в одном из проектов используют PM2 + его возможности для запуска различных типов worker-s. В другом написаны Unix services - которые запускают в нужном формате команды worker-s, где-то это просто cron-expressions. Данный подход позволяет: * работать с слоем БД (DAO) в одной кодовой базе и не размазывать его по разным репозиториям * использовать единую кофигурацию для подключений к БД, и различным 3rd party. Что бы не было ситуаций, а вот там вот забыл еще параметр обновить * можно собирать контейнеры под разный тип ворекров (в одном из проектов видел :) ) #### **Доклады** Вступительная KT - 20210513 - Фонові завдання (Background jobs)\ Видео: \ Слайды: