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.
Can you elaborate? I'm not sure whether you're saying this model is a bad model or a good model? I'd lean towards negative, but how is job scheduling "virtually irreplacable"?
