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.

• @see https://github.com/contribsys/faktory/wiki/The-Job-Payload

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.