Closed vemv closed 8 months ago
Hi, thanks for reaching out!
Whenever I have a handle-job!
function that needs more information (or state) than the Proletarian worker provides, I capture it from the scope where create-queue-worker
is called:
(defn handle-job! [{::keys [db mailer redis]} job-type payload]
;; handle the job...
)
(defmethod integrant.core/init-key ::worker [_ {::keys [db mailer redis]}]
(proletarian.worker/create-queue-worker db
(partial handle-job! {::db db
::mailer mailer
::redis redis})
{#_the-options-map})
,,,)
Would this work for you?
That seems to make sense!
I'll give it a try - update during the week hopefully.
This worked nicely.
Thanks for the suggestion!
Hi!
Thanks for the excellent lib.
I've noticed it's common for job handlers to require the Component/Integrant system to do anything useful.
(If not the entire system, it could be at least a specific component or selection of components).
e.g. a job handler will commonly need the database.
While I could save the Integrant system to a global var, that's not intended usage. It would also easily result in circular references.
I believe that a reasonable pattern/solution would be:
proletarian.worker/create-queue-worker
:payload-middleware
such that I can merge the system into each payload message.This is how it would look like for consumers:
(that's not technically middleware - other names welcome)
WDYT?
Thanks - V