Red Engine: modern scheduling framework for Python applications
red-engine.readthedocs.io
red-engine.readthedocs.io
To give a more useful answer though: it just uses cherrypy as a web framework and the zoom python bindings and sqlite. Nothing sophisticated, just a CRUD app that occasionally needs to download a large file and transcoded it in the background (which is where this scheduler will be used).
Unfortunately CDPR's latest RED Engine 4 will not be released as open source in the forseeable future, it's basically dead and locked away, and will probably never see the light of day. Maybe it would be open sourced but in something like 20 years time.
How would that work for other schedulers? Also, if a server reboots that's quite bad all round anyway. Hopefully you'd be notified directly.
[1]: https://red-engine.readthedocs.io/en/stable/tutorial/basic.h...
I don’t see any mention to serialization, so I guess this is single-server and memory only. I also couldn’t find any mention to error handling or retries.
“Red Engine is not meant to be the scheduler for enterprise pipelines, unlike Airflow, but it is fantastic to power your Python applications.”
One big issue I have with the proposed approach is that it's very difficult for me to see at a glance the actual compute graph. I suppose you can build some tools to visualize it from the DSL in the decorator call, but I'd much rather be able to see this directly in code, with no weird magic, so that I can very easily interpret and update it if need be.
from redengine import RedEngine
app = RedEngine()
@app.task('daily')
def do_things():
...
if __name__ == "__main__":
app.run()
> We initialized the RedEngine application, created one task which runs every 10 seconds and then we started the app. https://red-engine.readthedocs.io/en/stable/tutorial/quick_s...Might wanna fix that.
While we are on this: Do you know of any task scheduler framework that is similar to celery, but has better guarantees around task execution than what acks_late= True gives you?
I always find myself building a system that stores the really important Tasks in Postgres so that I can recover from anything in the broker or celery crashing. What i use celery for is just scheduling these Tasks by creating a celery job with the Postgres Job ID as the parameter.
Then, to detect if something went horribly wrong, I have a sweeping job that checks if any job in Postgres has not run in celery for some reason. If that is the case, we just re-queue the job.
Thus users could continue using RED, and if they want to scale to multiple machines or want resilience, you could allow them to switch out the backend to Flyte.
Disclosure: I am maintainer of Flyte. This is just a suggestion. Great work!
Correct me if I'm wrong, but the framework more powerful than Crontab and easier to use than Airflow is Celery. But Celery is not even mentioned here, why?
Many scheduling system I’ve worked with have this weird tendency to run when deployed and then every time it’s time for it to run.
I’ve had this happen with kubernetes, Scheduled Quries in GCP big query and a few other systems.
That seems like absolute madness. Why would anything do that?
Clouds have managed systems for scheduled jobs now (AWS Eventbridge, GCP Cloud Scheduler) which handle this for you.
Does Red Engine integrate with asyncio? When searching the docs for this keyword no hits showed up.
https://github.com/temporalio/sdk-python
Disclaimer: I work for Temporal
Ugh, no thanks.
First of all, English itself is not clean; it's a messy amalgamation of special cases and inconsistent spelling rules.
Second, it isn't actually English anyway. It might look like English, but it's actually a DSL that happens to correspond to English a lot of the time. English text is meant to be interpreted by humans, who understand context & connotation, and can resolve ambiguities by making educated guesses or discussing the text with other humans. But your English-like DSL can only be interpreted by a computer program, which cannot (and arguably should not) do such things. Ergo, the benefits of using natural language are lost, and you are left with the same strict interpretation rules as any other programming language, but without any of the syntactic rigor that would normally help you construct programs/expressions that are both syntactically correct and also do what you intended them to do. Finally, the passing similarity to another language is a newbie trap and it makes teaching more difficult. See also: SQL, Python.
Worse still, it's represented in code as a string literal. It cannot be reasonably syntax-highlighted or otherwise statistically analyzed, nor can it be easily constructed dynamically if needed, nor can scheduling primitives be combined or composed. It is the worst of all worlds, and you have no way to check if your program is valid other than to run it and see if it crashes. And you have to re-learn operator precedence / associativity rules, because they probably won't be identical to the rules in Python itself.
I'm sorry if there is a really high quality scheduling engine underneath this DSL, but I absolutely would never want to use something like this in production code.
(I'm sure you can guess how I feel about BDD frameworks and "expect.foo.to.be.equal.to" style test APIs).
@app.task('daily & is foo', execution="process")
followed by @app.task("after task 'do_daily'")
Yeah, I did a hard turn towards "nope" right there.Similar but not quite Python combined with similar but not quite English does not make a tasty dish. It makes yet another pointless one-off thing to learn and struggle with.
The only way I could see me struggle with this would be to piece together a large call graph in my head. I can understand why the author says that Airflow is better suited for this case because you get a visualization.
@app.cond('is foo')
def is_foo():
IMO @app.cond
def is_foo():
And 'losing' that you can omit the underscore to make it look a bit like English is much better. Plus then I can jump from its use back to this definition without any DSL-aware tooling (that probably doesn't exist).I do not see what is wrong with SQL and I definitely do not see what is wrong with Python.
and why not a proper python DSL?
from redengine import minute, hour
@app.run_every(hour + 20*minute)
def do_first(): [...]
@app.run_after(do_first)
def do_second1(): [...]
@app.run_after(do_first)
def do_second2(): [...]
@app.run_after(do_second1 and do_second2)
def do_last(): [...]