There are several reasons why I've chosen to go this route. First, you get a simpler codebase by structuring your application to use the provided events. This keeps users from rewriting code for different path handling. In my case, I have an addQueue function which all client requests go to. Depending on which request it is, it may get flagged for immediate use (an example is req info) while others get queued up for processing at a later time.

Furthermore, it's a much simpler codebase by being able to write code to use job info like IDs and such.

Edit:

I'm probably missing something but if no queue features are needed

Several queue features are still in use here. Namely, being able to have timeouts, events, job information, etc. The only feature not being used is concurrency limit. We want most jobs to respect concurrency limits (an example is bulk processing) whilst other jobs may not be resource intensive thus can run immediately. One workaround is to use two instances of Queue however this has the disadvantage of having duplicate code and multiple code paths.

Please see pull request #73 for an example. The work is also already provided for you with minimal changes.

Does this answer your question? Willing to provide some concrete examples.

Feature request: Immediately start a job #71

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions