Writing A Job Runner (In Elixir) (Again) (10 years later)

Just to add to the parent the Open Source version and the Pro Version just differs in that the Pro Version has a few plugins that the normal version has (for example workflows where you can have multiple workers working together) but it is not something you need for most use-cases.

Oban is great! This is definitely just met to be a learning exercise. But it could go quite a ways on its own in prod.

Do you worry about enshittification down the road?

Great write up, thanks for sharing! Nothing against Oban, but it is nice seeing someone in the Elixir community not just say, "run Oban" and drop the mic

I've run into this a few times before too. Sometimes discussing maintenance/ongoing costs and how minimal they are with an Elixir/Phoenix app can be compelling, though not always. I prefer to be over-transparent with clients so I'll usually add that if they plan to switch contractors often then it's probably not (tho sometimes still is) a good idea to go with Elixir. When I compare the amount of ongoing effort to keep a PHP, Node, or Python app running securely in prod with the ongoing effort with a Phoenix app, it's usually a better deal for them.

The one Danger Zone area though is when they want something between WordPress and a "real" app. A lot of the clients I've talked to already have WordPress and are really trying to stretch the framework to places it isn't really made to go. Those customers often think "I should be able to get a full app built for <=$10,000" and often shop around until they find someone who will accept it, and then they usually end up getting a bad/buggy product that is slow as dirt. At that point it's often too late as well because nobody wants to pay to start over. For those clients though I wouldn't recommend Elixir because they would almost rather spend more in maintenance costs than in initial development because the numbers feel smaller when spread out, even if they add up to more in the long run and with a much worse product.

That is not to say of course that any Elixir app is going to be better - there are bad Elixir devs just like any stack, though I think Elixir's relative lack of popularity actually leads to an overall more skilled dev pool.

It means they don't trust your judgement, aka you're just there to execute their plans. You're the floor guy, not the architect, owner, or developer of a house.

The problem is finding other people to work in less mainstream languages. Probably not an issue right now, but during better times...

If you have any feedback or anything is unclear feel free to open an issue. I am thinking I am going to take this and expand the concepts to start as a beginners primer going through the primary concepts in brief akin to Elixir School, and then expand it into building this and a web service that is using it and offering some real time features.

Thanks!

pgflow can be used with any language/runtime, I just started with TypeScript and Supabase, as that's what I'm using.

The worker is stateless and "dumb" by design (currently it runs on serverless functions) - it just calls SQL functions: "poll_for_tasks" to get some tasks from the queue and then either "complete_task" or "fail_task" after executing user code - that's it, nothing more, so it should be relatively easy to adopt it to other runtimes.

I have written a small architecture primer on pgflow if anyone is interested in its simple but flexible design https://www.pgflow.dev/concepts/how-pgflow-works/

That would be super cool. Pretty much everything Supabase is up to is awesome.

FOR UPDATE SKIP LOCKED is great, but it needs to be in a transaction. In the example code it won't "do" anything because it selects for update then immediately loses the lock.

Claude says you can use a CTE to select and the run your update with the locked rows, but I have only ever used transactions.

You also could use an advisory exact lock, which would serialize the order of input and force everyone to wait in line, but the advantage here is that we are allowed shared concurrent reads while maintaining our lock. Thank you for the feedback. It was fun to revisit after 10 years. The initial piece came after a Columbus, OH Ruby meetup that Jose attended. It was quite fun to see him put it together as a whole and I ran with things a bit further than his first ideas with this.