lcabrini
A few years ago a built a system in Go that I’m trying to rebuild as a part of learning more about Ash and Phoenix. This involved users being able to generate various reports relating to water bodies in West Africa. We got the data by talking to a remote web service. This was usually very slow and it could take quite a while to get a repsonse back. In addition, we were only supposed to allow a limited number of report requests to run at a time (a value that they admins could change). Once we got a reponse back we would pull out the relevant information from the JSON and send it to a report server which would generate a report and give us a link which we could pass on to the user. Do to issues with electricity and stuff, the pending jobs would have to be able to restart if something were to happen and the service needed to be restarted.
I’m interested in how to conceptually tackle this using Ash. I’m sure I could pretty much follow the procedure I did in Go, but it feels like Ash provides functionality that might be of use here. I’m looking at the state machine and/or possibly the reactor? I have really dug into these yet, but it “smells” like one or both of them might be useful in some way.
I’d like to know if there is some Ash-esque way of dealing with those requirements and what that would involve. The Go solution ended up working well enough, but the code was a bit of a nightmare both to maintain and to build upon.
Where Next?
Trending in Questions
Other Trending Topics
Latest Ash Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sorentwo
You don’t need Pro to rescue stuck jobs (orphans), that’s available with the standard Lifeline plugin. The difference with Pro is it isn’t as smart about restarts.
Side note—every persistent queue may either drop executing jobs silently (like Sidekiq), or you’ll have orphans that need to be dealt with. It’s a good thing!
jimsynz
Be careful with this approach if you plan on ever adding distribution or any kind of rolling deploys to the application. How can it tell that it’s starting clean or it’s starting while another instance is already running?
lud
If you need to be able to restart because of electricity shutdown, you must have your jobs-to-do in database. In that case a simple solution is to use Oban.
Oban will let you control how much workers you will have in your queue.
Infortunately if the server shutdowns during execution of an Oban job, on restart Oban will believe that the job is still “executing” and will not restart it (except if you use Oban Pro). But if you have a single instance of your application running, that is easy: On start, check if there is any job with the “executing” state in database and set it to “available”. And only then start the Oban queue.
Not sure how Ash could help there though.
Last Post!
lcabrini
Good point, but is not a problem in this particular case. But I’ll keep that in mind.