Ho hum. Another inbound marketing page with an interesting premise that turns out to be “we run all of the traditional infrastructure for you, and you pay us a lot.”

I think event-driven job processing is an interesting idea… it reminds me of Redux. If the pattern is interesting, it should be independent of a particular implementation of it.

Interesting. After having ran into an issue with having background jobs on Next.js apps that aren't just the frontend but utilizing the API aspect too, I ended up implementing a similar setup utilizing a queue service and a wrapper that allows me to "dispatch" a job anywhere in my app, that dispatched job has all the meta data needed, store it in redis like any other queue service built on redis does, but instead of a worker pulling from a queue bucket in the queue system and running it in a handler in the worker, the worker just pulls from the queue based on the job settings and essentially does a fetch call to an API endpoint to process that job.

The good old virtually-irreplacable-core-component-as-a-service model.

Isn't it cheaper to just use cloudflare worker cron to do the same thing, with logs, history, custom hooks etc?

Also, without unknown resource cost after limits are reached.

GCP Cloud Scheduler calls a GCP Cloud Function. Super easy (well documented), scalable, very little lock in, and not expensive at all.

https://cloud.google.com/scheduler/docs/tut-pub-sub