Publish Subscribe support

[tcoats]

We like pg-boss. A lot.

Does publish subscribe have a place in this codebase, or would you expect another library to extend pg-boss?

How publish subscribe could work:

1. A subscriptions table maps event names to queue names. Events are something new.
2. Subscriptions can be created and deleted.
3. When an event is published a new job is created for every queue in the subscriptions table against that event. Options and data remain the same and will operate on that job within the destination queue.

This allows more than one system to be 'notified' of an event.

Current terminology within the library makes this a little complex. Jobs are currently 'publish'ed and queues 'subscribe'd, however a more accurate description is send and process or similar. Two systems subscribing to the same queue will receive jobs independently. This is great for jobs that represent work to be done, however we'd like to use it for system notifications as well which requires two systems receiving the same job so they can act on it separately.

For publish subscribe the term job would ideally change to message.

Thoughts?

[timgit]

Thanks! I'm glad you guys are getting value out of this package.

First of all, I agree the typical semantics of pub/sub are not used in pg-boss. It's probably the biggest mistake I made when naming things 5 years ago in the API. I'm not against renaming all the things to make this more accurate in semantics to what is commonly accepted.

I think it would be useful to add pub/sub to the package in a similar way that cron-based scheduling found its way into the package after years of resistance (it was a lot of work, lol). ;) I'm not sure exactly what the new API would look like, but I imagine it would end up looking very similar to what you described here in the issue. This would basically behave like scheduling using a tracking table that correlates subscriptions to target queues.

[tcoats]

@timgit Is #272 is on the right track?

[timgit]

Sorry for the delay. I will review and likely merge it to a tracking branch to collaborate, post alpha releases and of course a bit of tire kicking.

[tcoats]

@timgit No worries! I appreciate you have other focuses. Happy to help out where I can, let me know.

[timgit]

@tcoats I've made some updates to the tracking branch primarily for docs, and I'm thinking I'd like to change the API from process() to work(). Just wanted to mention this to make sure you don't have any strong objections to the semantics. I noticed several references to internal types and variables named subscription, for example, and I already have quite a bit of internals named "worker" and "wip".

[tcoats]

@timgit All good on our end. Appreciate the involvement!

[timgit]

@tcoats this has been published to pg-boss@7.0.0-beta1 if you have a chance to kick the tires