1. Приложению необходимо обращаться к стороннему API для получения данных. Данный процесс может занять от нескольких секунд до нескольких часов, потому используются child процессы, чтобы не блокировать основной.
  2. Почему может быть так долго? Потому, что существует лимит у стороннего API по колличеству запросов на единицу времени. Если данный лимит превышен, child процесс ждет (а возможно должен быть убит) пока следующее обращение к API не будет возможно.
  3. Насколько я понимаю, необходимо создать оркестратор child-процессов, который сможет:

Условная схема текущей реализации

Untitled

Ответы

а в чем затык? Вроде все что ты описал реализуется стандартной библиотекой разве шо про ресурсы ¯\(ツ)/¯ я только pm2 пользуюсь активно для управления процессами в ноде

Eugene Obrezkov

cluster-ом вполне можно бить на процессы, но я не понимаю зачем, если можно worker threads использовать. ну и стараться не делать блокирующие операции, конечно. и тем более ждать в потоке, пока АПИ проснется

Eugene Obrezkov, [12/9/2021 4:02 PM] https://nodejs.org/dist/latest-v16.x/docs/api/cluster.html#how-it-works

Alexander Klochko

А чем не подходят стандартные job queue с воркерами? Плюс, если боттлнек в апи, а не в вычислительных ресурсах, то скорее даже одного "воркер"-сервиса будет достаточно

Eugene Sherlaimov

Я подозревал, что есть какой-то стандартный подход к решению задачи, о котором я не знаю. У меня монорепа, в которую входят следующие под-проекты: сервер, клиент, shared и парсер. В описанной мною проблеме происходит взаимодействие между сервером и парсером, которые вообще не знают друг о друге.

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

Obrezkov