4 ms·
Looking more at things like #2. Sidekiq isn't terrible though, and if you get big enough, you're going to want some more management than just spawning a BEAM pr
by davidw 5y ago
Looking more at things like #2. Sidekiq isn't terrible though, and if you get big enough, you're going to want some more management than just spawning a BEAM process to do something. What have people settled on for that with Elixir/Erlang?
- hanrelan 5y agoYou could use something like oban: https://github.com/sorentwo/oban https://github.com/sorentwo/oban
- tptacek 5y agoSidekiq is great, but it is a thing you have to think about (in particular, how you're shuttling state from workers to a place where front-end can see it). The big win with Phoenix as I understand is not having to think about it at all: it has a natural expression in the language and the platform, and that expression is performant.
- davidw 5y agoIf it's just a small fire and forget thing in Erlang, you can just spawn the process, sure. My point is that once people start to care about what happens with those background jobs, you probably need some infrastructure around them, and then the Erlang thing might start to resemble Sidekiq a bit more.
- joelbluminator 5y agoThis. "When we want to have more control, i.e. persistence on disk, a workers pool, retries, among other things, there are several popular solutions: Oban: a robust PostgreSQL-based queue backend process system. It has a UI in its pro version Exq: a Redis-based Resque and Sidekiq compliant processing library. It has an open source UI exq_ui verk: same as Exq. Is is compatible with Resque and Sidekiq job definitions" https://sipsandbits.com/2020/08/07/do-we-need-background-jobs-in-elixir/ https://sipsandbits.com/2020/08/07/do-we-need-background-job... So basically sounds to me like Elixir is doing pretty much the same thing as Ruby. We usually do want more control and disk persistence, so...