Introducing Scheduled Triggers: API Driven Cron Jobs and Scheduled Events

We are happy to announce the stable release of v1.3 bringing in a slew of features like Data Federation via Remote Joins, Support for Relay and Scheduled Triggers.

Scheduled Triggers are used to execute custom business logic at specific points in time. It extends the idea of Event Triggers, which are driven by database events, to a flexible API that can be used to schedule events for any payload and webhook to be run in the future.

Scheduled Triggers are a great fit with serverless because each event can be mapped to an individual function that doesn't need to be highly available and can be queued and executed.

There can be two types of scheduling:

Cron Triggers

• Run periodic events on a cron schedule.

One-off Scheduled Events

• Schedule an event to run only once, typically created via API calls.

How does it work?

The client schedules an event through the Hasura metadata API giving the payload and the webhook URL that needs to be invoked at a given timestamp (or cron schedule). Hasura then stores this metadata in the database and processes these events in the background, delivering them at the configured timestamp. Similar to Event Triggers, Hasura stores the full logs of every invocation.

API driven scheduling

Events can be scheduled from both the console or through metadata APIs. If your cron configuration is static, then it can be created using the Console UI using the good old cron expression. Or if you want to quickly schedule a one-off event, that can be done through the UI as well.

But suppose your event payload is dynamic, then you would typically be scheduling an event via an API which performs some business logic. The simplest API call to schedule a one-off scheduled event will look like:

{
  "type": "create_scheduled_event",
  "args": {
    "webhook": "https://my-awesome-serverless-fn.com/send-email",
    "schedule_at": "2022-07-20T12:45:00Z",
    "payload": {
      "email": "[e-mail]"
    }
  }
}

You can also view all scheduled events in the console and delete them if needed.

Actions & Scheduled Triggers

Scheduled triggers goes well with Hasura Actions as you would typically create a scheduled event as part of a mutation with custom business logic. Let's take the example of scheduling a tweet: You will create a custom mutation through Actions and define the logic to validate and insert the tweet into the database. Once the payload is validated, you will be calling the create_cron_trigger or create_scheduled_event for the specified timestamp and the event delivery will be taken care by Hasura.

Both Actions and Scheduled Triggers nicely fit in the serverless pattern as the source of data and logic is spread across different APIs. Of course you are not limited to serverless architecture, since all Hasura needs is a valid HTTP POST endpoint.

Fault Tolerance

If Hasura is down, newer events won't be scheduled or existing events wouldn't be processed temporarily. But what happens when the server is back up and running? In this case, the existing events that were scheduled to run would be (re)triggered based on a customisable tolerance configuration.

For example: If an event was scheduled for 12am and Hasura went down at 11:59pm and came back up at 12:01am, depending on the tolerance config (denoted in seconds), Hasura will attempt to deliver these past events that were not triggered.

Hasura also gives a flexible retry configuration to retry the event n number of times in case of a failure and ability to set an interval gap between each retry, so that your webhook doesn't get overloaded.

Metadata workflow

Cron triggers will usually be part of your metadata. As long as the payload doesn't contain user/session data, it makes sense to have cron triggers a part of your metadata so that it can be migrated between different instances (ie. staging, production).

One-off scheduled event will be temporary state that can be archived once the event is delivered. It doesn't need to be part of your migrations and metadata workflow and the state is persisted in the database to examine the status of the event.

Use Cases

The typical uses for cron triggers are recurring events like:

• Daily reports
• Automated weekly newsletters
• Recurring reminders

Use cases for one-off scheduled event:

• Schedule a tweet for tomorrow at 2:30pm
• Send a feedback email to user after a week post order delivery in an e-commerce app

We did a demo in one of our community calls earlier and you can check it out to see how events can be scheduled both via Console and through an API.

Hasura Community Call - Scheduled Triggers Demo

---

Try it out!

Get started with Scheduled Triggers on Hasura Cloud today!

If you're already running Hasura, make sure you're on version 1.3 or above and you're good to go!

---