SlayQ Server

The SlayQ server is a wrapper around Graphile Worker. It must be deployed to a server and run 24/7. You cannot deploy it to a serverless environment.

Configuration

To run the SlayQ server you must first configure your environment and create a slay-config.json configuration file that contains information about your queues.

Environment Variables

SlayQ server expects the following environment variables to be defined:

SLAY_Q_DATABASE_URL - The connection string url for your postgres database.
SLAY_Q_SECRET - The secret used to sign events posted to your app's slay-q receiver endpoint.
SLAY_Q_CRON_URL - The URL to your slay-q receiver endpoint that will receive cron events. If you are running in a docker image and attempting to access a dev server running on localhost, you should use http://host.docker.internal:3000/ instead of http://localhost:3000.

Queue Configuration

You must create a file named slay-config.json and pass it as an argument to the SlayQ server. The configuration file looks like:

slay-config.json

{
  "queues": {
    "mail": {
      "concurrency": 4
    },
    "messaging": {
      "concurrency": 6,
      "alias": [
        "dispatch",
        "ready"
      ]
    },
    "interactions": {
      "concurrency": 1,
      "alias": [
        "reconcile",
        "discord"
      ]
    },
    "housekeeping": {
      "concurrency": 2
    },
    "profile": {
      "concurrency": 8
    },
    "general": {
      "concurrency": 10
    }
  }
}

We are essentially defining a variety of queues and their level of concurrency (the number of tasks that can run at once in the queue). Additionally, we are specifying aliases for these queues. These aliases are only provided to help keep things organized on the client side of things. For example, the messaging queue has the aliases "dispatch" and "ready". These are just additional identifiers, it doesn't mean we are defining three additional queues with the same properties. Therefore, the concurrency will be shared with aliases.

Database Migrations

The first time you run the server, two migrations will be run:

A schema and related tables called graphile_worker will be created. This schema is required for Graphile Worker to function.
A second schema and related tables/function called slayq will be created. This contains all the tables and functions SlayQ needs to do its housekeeping.
Additionally, a few functions will be created in the public schema. This is necessary for Supabase as you cannot access other schemas with their js libs.

Run via Docker

The recommended approach is using docker via our slaypics/slay-q-server docker image.

docker-compose.yml

version: '3.1'
services:
  slay_q_server:
    image: slaypics/slay-q-server
    restart: always
    environment:
      - SLAY_Q_DATABASE_URL=postgresql://postgres:postgres@slay_q_postgres:5432/postgres
      - SLAY_Q_SECRET=G,4DgB$.?>X]"w}w1745Xq2nKoM4BG74
      - SLAY_Q_CRON_URL=http://host.docker.internal:3000/api/slay-q
    volumes:
      - './slay-config-sample.json:/home/node/app/slay-config.json:ro'
volumes:
  slay_q_postgres:

Run via Command Line

Run:

npx slay-q-server /path/to/slay-config.json

Run without installing:

npx @slay-pics/slay-q-server@latest /path/to/slay-config.json

GuideSlayQ Client