Jobs
Named background work: register a handler for a job name, enqueue work under that name, and start the consumers. It sits on b.queue and adds the registry, so the name a producer writes and the handler a consumer runs are checked against each other rather than agreeing by convention.
Enqueuing a name no handler is registered for is refused, because that work would sit in the queue and never run while the enqueue call reported success. A deployment that produces on one node and consumes on another opens that case deliberately with allowUnregisteredEnqueue.
Handlers are registered before start() and refused after it, so the set of consumers a process runs is fixed at the point it starts running them.
b.jobs.create(opts?) #
{
queueBackend: string, // b.queue backend name; default "primary"
consumerDefaults: object, // consumer options every job starts from
allowUnregisteredEnqueue: boolean, // default false — enqueue a name nothing handles
}Open a job registry and answer the handle to work it. The handle carries define(name, handler, opts?), enqueue(name, payload, opts?), start(), shutdown(opts?) and stats().
define refuses a duplicate name and refuses to run after start(). enqueue refuses a name nothing handles unless allowUnregisteredEnqueue is set, which is for the deployment that enqueues on a node that does not consume. start() subscribes every registered name and is safe to call twice. stats() answers the defined names and whether the consumers are running.
Per-job options given to define override consumerDefaults for that job alone, so one slow job takes a longer timeout without widening it for the rest.
var b = require("@blamejs/core");
var jobs = b.jobs.create({ consumerDefaults: { concurrency: 4 } });
jobs.define("email.send", async function (payload) {
await b.mail.create().send(payload);
});
await jobs.start();
await jobs.enqueue("email.send", { to: "a@b.test" });