Repeater.dev lets you execute tasks at a predefined time or on a recurring basis. Repeater is particularly good at calling an HTTP endpoint at a specific time and recording the result. It is built with RedwoodJS and was created by RedwoodJS core contributor Rob Cameron.

Potential jobs you can schedule include:

• Send emails & notifications
• Check for heartbeat
• Image processing
• Data transformations
• PDF generation

Repeater is accessed through a GraphQL API:

• https://api.repeater.dev/graphql

If your client is capable of doing so you can issue an introspection query and receive a list of queries and mutations you can perform. repeaterdev-js is an official Javascript library that you can also use to skip worrying about your own GraphQL calls.

A typical workflow with Repeater may look something like:

1. Create an Application
2. Create one or more Jobs to be run in the future
3. After a Job has run check the JobResult to confirm it completed successfully (or if it failed, why?)

Getting Started

First you'll need to create an account at repeater.dev. After logging in you can create an Application to serve as the owner of any Jobs you create.

The random token that's generated along with your Application will serve as your access token for the API.

Authentication

Once you have the token from your Application you must include that in the header of every GraphQL call in the form of a Bearer token.

If you are using the repeaterdev-js library you create a new instance using your token as the first argument.

Authorization: Bearer 8edd2e13df6b840d23b47b0af177a62a

curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 8edd2e13df6b840d23b47b0af177a62a" \
--data '{ "query": "{ jobs { name } }" }' \
https://api.repeater.dev/graphql

const repeater = new Repeater('8edd2e13df6b840d23b47b0af177a62a')

Applications

Top-level container for your Jobs

If you have two deployed webapps that need scheduled job processing, you would have an Application for each. Each would have a unique name. Creating an Application generates a unique token for authenticating each GraphQL API request.

You can only create Applications via the repeater.dev UI at this time. However you can request Application details as a field on other queries, like Jobs.

query {
  jobs {
    name
    application {
      name
      token
    }
  }
}

Jobs

Main components of Repeater

A Job will contain a URL to hit somewhere on the internet and record the response as a JobResult. Jobs can be run once or on a recurring basis.

A Job must have a unique name (unique among its parent Application) which will act as its unique identifier for all query and mutation operations.

jobs

Query that returns all Jobs for the Application used to authenticate

query {
  jobs {
    name
    enabled
    endpoint
    verb
    headers
    body
    retryable
    runAt
    runEvery
    createdAt
    updatedAt
    lastRunAt
    nextRunAt
  }
}

const jobs = await repeater.jobs()

job

Query that returns details for the given Job name

A name argument is required (String) for the name of the Job.

query {
  job(name: "test-job-1") {
    name
    endpoint
  }
}

const job = await repeater.job('test-job-1')

createJob

Mutation that creates a Job

If a value is given for runEvery then the Job will run on that recurring schedule. Otherwise it will only run once at runAt.

mutation {
  createJob(
    name: "test-job-1"
    endpoint: "https://myapp.com/api/sendEmail"
    verb: "post"
    runAt: "2020-07-24T22:00:00Z"
    headers: "{\"Content-Type\":\"application/json\"}"
    body: "{\"foo\":\"bar\"}"
  ) {
    name
  }
}

const job = await repeater.enqueue({
  name: "test-job-1"
  endpoint: "https://myapp.com/api/sendEmail"
  verb: "post"
  runAt: new Date,
  headers: { 'Content-Type': 'application/json' }
  json: { foo: 'bar' }
})

updateJob

Mutation that updates a Job

Any existing Runners will be canceled and re-scheduled with the new runAt and runEvery arguments. Its arguments are the same as createJob attributes except that all attributes are optional except name.

You cannot change the name of a Job. Updating a Job first looks up the Job by the provided name argument and that's the one that is updated. Renaming a Job would be equivalent to deleting the existing one and creating a new one with the new name.

mutation {
  updateJob(
    name: "test-job-1"
    verb: "get"
  ) {
    name
  }
}

const job = await repeater.job('test-job-1')
await job.update({
  verb: "get"
})

createOrUpdateJob

Mutation that updates Job with provided name or creates Job with that name

If a Job is found with the provided name it is updated with the new values, otherwise a Job is created with that name. Its arguments are the same as createJob.

mutation {
  createOrUpdateJob(
    name: "test-job-1"
    endpoint: "https://myapp.com/api/sendEmail"
    verb: "post"
    runAt: "2020-07-24T22:00:00Z"
    headers: "{\"Content-Type\": \"application/json\"}"
    body: "{\"foo\":\"bar\"}"
  ) {
    name
  }
}

const job = await repeater.enqueueOrUpdate({
  name: "test-job-1"
  endpoint: "https://myapp.com/api/sendEmail"
  verb: "post"
  runAt: new Date,
  headers: { 'Content-Type': 'application/json' }
  json: { foo: 'bar' }
})

deleteJob

Mutation that deletes a Job and any pending Runners

This will also remove any JobResult history. A name argument is required (String) for the name of the Job.

mutation {
  deleteJob(name: "test-job-1") {
    name
  }
}

const job = await repeater.job('test-job-1')
await job.delete()

JobResults

The record of what happened when a Job was run

JobResults have their own endpoint but can also be returned as a sub-type of Jobs themselves.

jobResults

Query that if given the jobName argument returns all JobResults for that Job

Otherwise it returns all JobResults for the Application used to authenticate. A jobName argument is optional (String) for the name of a parent Job.

query {
  jobResults(jobName: "test-job-1") {
    status
    headers
    body
    runAt
    run
    duration
    createdAt
    updatedAt
  }
}

const job = await repeater.job('test-job-1')
const results = await job.results()

Runners

Represents the actual processes that execute your Job

You will only see Runner records for Jobs that are actively running or still scheduled to be run in the future. There is no stand-alone Runners query. You can only return Runners as a sub-type of a Jobs query.

query {
  jobs {
    name
    runners {
      priority
      queue
      attempts
      recurring
      running
      runAt
      failedAt
      createdAt
      updatedAt
    }
  }
}