4 ms·

> But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they tak

> But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up. I'm pretty sure this isn't true at all with Rails. Out of the box you get Solid Queue (jobs), and Solid Cable (real time messaging).

nop_slide 1y ago
Yeah def odd, I'm a recent rails convert and SolidQueue is dead simple and is setup out of the box. When paired with https://github.com/akodkod/solid-queue-dashboard https://github.com/akodkod/solid-queue-dashboard you get a nice overview.
- jamiecurle 1y ago
  I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years). Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff. Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
  - conradfr 1y ago
    That's also where I'm at. For any project with UI (and auth/auth etc) I went back to Symfony (and Vue). I can't stand Phoenix templating especially layouts and I couldn't convince José of the greatness of template inheritance like with jinja2 in python ;) But I'm happy running worker type things in elixir & Phoenix if I can.
  - pmontra 1y ago
    IMHO Django's templating engine is its worst feature but that only proves how subjective all these matters can be. I'm currently making money both from Django and Rails. I made quite a bit of money from Phoenix years ago. Customers choose their platforms, I can choose customers. About OTP's primitives, they are great but a background job system has more features than those primitives offer. We wrote a fair amount of extra code to get what we needed for our production system. I'm using Sidekiq in Rails in my current Rails project and it's more feature complete than what we built for Phoenix. I'm using Celery with RabbitMQ in my current Django project and we would like to get rid of it. It's too fragile.
akarshc 1y ago
All the things are possible in rails as well. it is a beautiful framework, but it is so much easier to use with phoenix. Do try it out
sergiotapia 1y ago
Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork. Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults. Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev. Solid Queue I'm bearing because I get other stuff I need from Rails.
- sorentwo 1y ago
  > Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. Maybe it is obvious in retrospect…
  - sergiotapia 1y ago
    I did not mean to diminish the implementation, of course it must be incredibly complex. I meant all that complexity is hidden from me, the developer. It's really easy to understand what to do. :D
- JamesSwift 1y ago
  > Solid Queue I'm bearing because I get other stuff I need from Rails. I mean sidekiq is tried and true
  - sergiotapia 1y ago
    I don't want to pay for a redis instance. On principal! coming from elixir thats an ick haha
tvink 1y ago
Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.

nop_slide 1y ago

Yeah def odd, I'm a recent rails convert and SolidQueue is dead simple and is setup out of the box. When paired with https://github.com/akodkod/solid-queue-dashboard https://github.com/akodkod/solid-queue-dashboard you get a nice overview.

jamiecurle 1y ago
I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years). Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff. Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
- conradfr 1y ago
  That's also where I'm at. For any project with UI (and auth/auth etc) I went back to Symfony (and Vue). I can't stand Phoenix templating especially layouts and I couldn't convince José of the greatness of template inheritance like with jinja2 in python ;) But I'm happy running worker type things in elixir & Phoenix if I can.
- pmontra 1y ago
  IMHO Django's templating engine is its worst feature but that only proves how subjective all these matters can be. I'm currently making money both from Django and Rails. I made quite a bit of money from Phoenix years ago. Customers choose their platforms, I can choose customers. About OTP's primitives, they are great but a background job system has more features than those primitives offer. We wrote a fair amount of extra code to get what we needed for our production system. I'm using Sidekiq in Rails in my current Rails project and it's more feature complete than what we built for Phoenix. I'm using Celery with RabbitMQ in my current Django project and we would like to get rid of it. It's too fragile.

akarshc 1y ago

All the things are possible in rails as well. it is a beautiful framework, but it is so much easier to use with phoenix. Do try it out

sergiotapia 1y ago

Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork. Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults. Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev. Solid Queue I'm bearing because I get other stuff I need from Rails.

sorentwo 1y ago
> Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. Maybe it is obvious in retrospect…
- sergiotapia 1y ago
  I did not mean to diminish the implementation, of course it must be incredibly complex. I meant all that complexity is hidden from me, the developer. It's really easy to understand what to do. :D
JamesSwift 1y ago
> Solid Queue I'm bearing because I get other stuff I need from Rails. I mean sidekiq is tried and true
- sergiotapia 1y ago
  I don't want to pay for a redis instance. On principal! coming from elixir thats an ick haha

tvink 1y ago

Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.