Bridge Faktory and Postgres
Remember the old times when our grandfathers could not publish job payloads from Postgres to Faktory?
These dark days are over!
Installation
YARN
$ yarn global add postgres-faktory-bridge
NPM
$ npm install -g postgres-faktory-bridge
Usage
Start the bridge
# Environment variables
POSTGRESQL_URL=
FAKTORY_URL=
POSTGRESQL_DEFAULT_CHANNEL=
POSTGRESQL_CHANNEL_MAP=
JOB_DEFAULT_QUEUE=
JOB_DEFAULT_PRIORITY=
JOB_DEFAULT_RESERVE_FOR=
JOB_DEFAULT_RETRY=
JOB_DEFAULT_BACKTRACE=
JOB_DEFAULT_TYPE=
# Example
$ export POSTGRESQL_URL=postgres://user:pass@host:port/dbname
$ export FAKTORY_URL=127.0.0.1:7419
$ postgres-faktory-bridge
Notify a channel and publish a job
Example
SELECT pg_notify('faktoryJob', '{"queue": "MyQueue", "jobType": "MyJobType", "args": [1,2,3]}');
The job is created by using the LISTEN/NOTIFY
notification system from Postgresql: NOTIFY channel [ , payload ]
The payload send by the Postgres notification is used as the job payload for Faktory.
The passed in options by the notification system will take presedence over the default environment variables - if present. The exception from this rule is: When there is a queue name mapped to channel - this queue will always be used.
JOB_DEFAULT_QUEUE=
JOB_DEFAULT_PRIORITY=
JOB_DEFAULT_RESERVE_FOR=
JOB_DEFAULT_RETRY=
JOB_DEFAULT_BACKTRACE=
JOB_DEFAULT_TYPE=
The default channel is called FaktoryJob
and can be overwritten by the environment variable POSTGRESQL_DEFAULT_CHANNEL
.
It is also possible to create a comma seperated list of channel and queue names in POSTGRESQL_CHANNEL_MAP
.
The command syntax is: CHANNEL:[QUEUE]
$ export POSTGRESQL_CHANNEL_MAP=myChannel:anotherQueue,justAnotherChannel
When there is only a channel name - the current default queue in Faktory is used.
Things to consider
- The bridge process can only be run on one machine/container etc. Otherwise every listening bridge will create a job in Faktory.