I’ve been implementing every new API point that doesn’t use ActiveRecord business logic as an HTTP service in Elixir. It’s been working out great - seeing lots of advantages: easier development, fast, low memory.
dogweather
dwahyudi
The easiest way to this is to make an independent Elixir (web)app. Rewrite some of your Rails app code with Elixir code and let the Rails app communicate with that Elixir app via rest HTTP.
If necessary, let the Elixir app access the same database and probably share the users session (if any) with the Rails app.
The downside is of course on the added latency when communicating between these two.
0
eidge
We’ve been using a similar strategy for our push notification needs.
The basic architecture is Rails enqueues jobs in Redis (using Resque), but these jobs never get consumed by Resque. Instead an Elixir app running Exq consumes and runs these jobs.
It’s been pretty much smooth sailing consuming up to thousands of jobs per second. It is however extra infrastructure complexity (one more machine to provision, run and monitor along with a different technology stack to maintain, and learn how to run in production). In our case this complexity was well justified by the simplicity of the implementation and the load it withstands - 2 weeks worth of implementation.
If we were using Ruby, we would need a lot of processes (and therefore memory) to be able to run at the same level of concurrency.
Your mileage might vary though.
3
cjbottaro
I don’t understand why people keep pushing things like this when the author of Sidekiq himself has created a language agnostic Sidekiq called Faktory. Where the mission statement is practically, “You know how ubiquitous and awesome Sidekiq is? Now it’s available in any language.”
Just sayin…
Look, I’m an Elixir zealot at this point, and I want the language to succeed. And I think normalizing around something like Faktory as the defacto standard can help with that.
0
cjbottaro
If it wasn’t immediately obvious from the previous post, the official Faktory wiki lists an Elixir client.
Full disclaimer, I’m the main author of the Elixir client and I also worked with Mike Perham years ago.
0
axelson
Scenic Core Team
Well the (upcoming) pricing
“Advanced features for the advanced business, Price TBD.”
Is a reason to be wary. I know some of the features under Sidekiq Pro/Enterprise are features that could be considered to be important to a large number of use cases (such as rate limiting and periodic jobs), but generally I’m just trying to provide insight into the multiple available options.
1
cjbottaro
If you don’t want to write/manage these features… someone else will do it for you… for a price.
My company used Sidekiq Pro for about 3 years, then abandoned it for OS Sidekiq with our own, in house developed middleware and extensions.
What’s there to be wary about? It’s literally open source.
0
beaorn
I think to have robust features with a level of support business critical applications require, the model that Mike Perham has taken with sidekiq and going to take with faktory is ideal. You get great features for free that are open source that people can build solutions on top of, BUT if they dont exist out in the open source space or the ones that do arent maintained, you can get enterprise level features through the paid levels they provide. I also think that lets him (and any team) make a living keeping the open source implementations maintained alive and usable that tons of apps are using for free. I’m pumped about faktory 1.0
1
axelson
Scenic Core Team
In case anyone is still coming to this thread (based on views it appears so). Another good option for running persistent background jobs in Elixir is GitHub - oban-bg/oban: 💎 Robust job processing in Elixir, backed by modern PostgreSQL, SQLite3, and MySQL · GitHub (this is the job library that I like to use).
7