RFC: 009 - hyper Scheduler Service

[twilson63]

Background

Many times, applications need to schedule things to happen in a re-occurring manner, giving the ability for the application to submit a scheduled job/task, that consists of criteria that identifies the time of notification and a target endpoint to notify, can allow applications to programmatically schedule job/tasks to be performed while coding the job/task via a web service endpoint.

Features

• create - create scheduled job/task
• delete - delete scheduled job/task
• list - list scheduled jobs/tasks

Model (What is a job/task)

{
  "name": "name of job/task",
  "cron": "cron criteria for task execution ex: * * * * * (every 1 minute)",
  "target": "URL to notify at scheduled cron time"
}

Proposed Adapters

1. hyper-adapter-eventbridge uses AWS EventBridge to create scheduled Events + Lambda
   See: https://aws.amazon.com/blogs/mt/build-scheduler-as-a-service-amazon-cloudwatch-events-amazon-eventbridge-aws-lambda/

2. hyper-adapter-cron uses a deno cron library and local persistent store (dndb) to create a scheduler service
   See: https://github.com/rbrahul/deno_cron, https://deno.land/x/[email protected]

[TillaTheHun0]

I like the idea. This is definitely something that many apps end up needing. Also, I feel fairly straightforward to implement.

A common use case I see is needing to attach a payload to the scheduled notification, to provide context to the handler. I've seen this payload passed as query parameters on the target URL, and also as JSON to the target url. JSON feels more kosher to me, personally.

So model might be:

{
  "name": "name of job/task",
  "cron": "cron criteria for task execution ex: * * * * * (every 1 minute)",
  "payload": "JSON to send in the body to the target URL"
  "target": "URL to notify at scheduled cron time"
}

Additionally, clients will need to be able to verify requests from hyper, so some sort of strategy will need to be implemented/documented for clients to check that the request came from hyper, and hasn't been tampered with.

[twilson63]

Cool, like all of your suggestions,

RE: verify, we can do this a number of ways, I do like the JWT approach:

{
   ...
   "[jwt]": { "sub": "", "aud": "", "secret": "" }  
}

• [] square brackets indicate optional property

[TillaTheHun0]

Slack uses a clever way to verify identity and that the request wasn't tampered with, in the same operation: https://api.slack.com/authentication/verifying-requests-from-slack