Live data from Hacker News

Oban, the job processing framework from Elixir, has come to Python

dimamik.com

71–80 of 107 posts

Re: Oban, the job processing framework from Elixir, has come to Python

#71
post #11

> Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…

Debezium was built exactly for that to power a queue based on WAL.

Re: Oban, the job processing framework from Elixir, has come to Python

#72
post #4

This is something my company has been considering for a while. We've been using celery and it's not great. It gets the job done but it has its issue. I've never heard of Oban until now and the one we've considered was Temporal but that feels so much more than what we need. I like how light Oban is. Does anyone have experience with both and is able to give a quick comparison? Thanks!

We migrated from Celery to Prefect a couple of years back and have been very happy. But ours is a small op which handles tasks in 1000s and not millions. It’s been night and day in terms of visibility and tracking. I would definitely recommend it.

It’s a heavy weight that covers a lot of use cases. But we just run simple ProcessWorkers for our regular needs and ECS worker for heavier ML tasks.

Re: Oban, the job processing framework from Elixir, has come to Python

#73
post #70

Is Postgres fast enough for job processing these days? We do hundreds of millions of jobs now and even years ago when our volume was a fraction of that, we got a huge performance boost moving from Postgres + Que to Redis + Sidekiq. Has that changed in the intervening years?

Hundreds of millions over what time frame? I got a system with Rails/Solid Queue + Postgres and doing about 20M jobs/day on a $45/mo VM with plenty of room to spare.

Re: Oban, the job processing framework from Elixir, has come to Python

#74
post #11

> Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…

Lots of people are also trying to just use postgres for everything, tho.

Re: Oban, the job processing framework from Elixir, has come to Python

#75
post #13
post #4

This is something my company has been considering for a while. We've been using celery and it's not great. It gets the job done but it has its issue. I've never heard of Oban until now and the one we've considered was Temporal but that feels so much more than what we need. I like how light Oban is. Does anyone have experience with both and is able to give a quick comparison? Thanks!

Very, very different tools, though they cover similar areas. Temporal - if you have strict workflow requirements, want _guarantees_ that things complete, and are willing to take on extra complexity to achieve that. If you're a bank or something, probably a great choice. Oban - DB-backed worker queue, which processes tasks off-thread. It does not give you the guarantees that Temporal can because it has not abstracted…

I’ll say that, I think this varies by language/SDK - at least with the Temporal TypeScript SDK, a simple single idempotent step background task is however many lines of code to do the actual work in an activity, and then the only boilerplate is like 3 lines of code for a simple workflow function to call the activity.

Re: Oban, the job processing framework from Elixir, has come to Python

#76

Is there a web U/I to view jobs, statuses, queue length etc?

There is one for elixir that is _mostly_ compatible with oban-py. Full compatibility, and potentially native hosting, are goals before 1.0

https://github.com/oban-bg/oban_web

Re: Oban, the job processing framework from Elixir, has come to Python

#77
post #11

> Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…

We're building an AI powered app builder. We use elixir, phoenix and of course OBAN.

It feels like such a super power. What you're describing is particularly important in the era of long running AI processes. Something as simple as running a deploy creates pressure on your agent orchestration. But if everything is powered by OBAN you have wonderful ways to build durability.

By the way, it's all "free" and built-in.

In other language ecosystems, people literally pay for durability that has this shape (like temporal)

Re: Oban, the job processing framework from Elixir, has come to Python

#79
post #3

While this is a Cool Thing To See, I do wish things would go the other way—and have all the BI/ML/DS pipelines and workflows folks are building in Python and have them come to Elixir (and, as would follow, Elixir). I get where the momentum is, but having something functional, fault-tolerant, and concurrent underpinning work that’s naturally highly concurrent and error-prone feels like a _much_ more natural fit.

Agree, and Claude Code does very well with Elixir despite TS/Python getting all the hype: https://youtu.be/iV1EcfZSdCM?si=KAJW26GVaBqZjR3M This helps with keeping it on track writing idiomatic elixir and using good patterns: https://skills.sh/agoodway/.claude/elixir-genius

> # WRONG: Elixir has no elsif

How much context is eaten up by skills that rehash what a SOTA model should already know?

Maybe token-wise, it's a wash: Elixir/OTP does a lot without third-party libs, which would require massive npm dependencies to achieve the same thing.

Post reply on HN