4 ms·

I really have to disagree. My perspective is somebody that did some Rails work >10 years ago, followed the hype/money into Node.js and eventually Go, then ended

by grncdr 4y ago

I really have to disagree. My perspective is somebody that did some Rails work >10 years ago, followed the hype/money into Node.js and eventually Go, then ended up working in Rails again ~4 years ago. In my experience a bog-standard vanilla Rails + Postgres setup provides all of the things you mentioned (except presence awareness, which is pretty tricky). * Server push. Websockets. Push notifications. => ActionCable * Scheduled jobs. Long running background jobs. => ActiveJob * Calls into other services. => Pick your preferred HTTP library (or just use Net::HTTP) All of the above have been part of Rails for years. The only additional Gem I would add is good_job to be the ActiveJob backend. Now, if you start to bump up against what vertically scaling Postgres can handle, or you want some of the _additional features_ of a 3rd party dependencies (Redis, Sidekiq, Webpack, etc. etc.) you can easily add them, but it's realllly unnecessary for 99% of apps out there.

quickthrower2 4y ago
What is presence awareness?
- grncdr 4y ago
  I will just steal the first paragraph from https://hexdocs.pm/phoenix/presence.html https://hexdocs.pm/phoenix/presence.html, but you can read much more about it there. > Phoenix Presence is a feature which allows you to register process information on a topic and replicate it transparently across a cluster. It's a combination of both a server-side and client-side library, which makes it simple to implement. A simple use-case would be showing which users are currently online in an application.
  - quickthrower2 4y ago
    I see! Funny enough the app of the company I work for does this. The tech is simply running a stateful server behind the web server.
cpursley 4y ago
All those things you listed require additional background servers, redis, etc. In Elixir/Erlang, it's built into the runtime which is a huge advantage. And even with standard things like handling http requests in Elixir -absolutely smokes Ruby in terms of performance. This leads to real cost savings as well
- silasb 4y ago
  Those built-ins that you are talking about are not as well rounded as a dedicated framework. These built-ins operate at a different operating model than running additional background servers. This typically means that everyone in the org needs to be an Elixir/Erlang expert instead of having experts in Redis, cloud native, ... For better or worse, this is likely a large obstacle for many orgs. The argument for using Elixir/Erlang is also more difficult when you have large companies like Github and Shopify demonstrating that Ruby can scale. EDIT: Let's not forget that it's mostly the DB that slows CRUD apps down. Not the language or the framework.
- grncdr 4y ago
  No, they don't. You can absolutely run ActionCable with the postgres adapter in your main rails app server and require no additional services. Edit: this is also why I mentioned GoodJob, it supports the full ActiveJob API (delays, retries, etc), even comes with a nice Web UI, and it only requires Postgres.
  - cpursley 4y ago
    I'm using Quantum as my job runner in Elixir. Doesn't require even Postgres. Can't do that in Rails or other stacks: https://github.com/quantum-elixir/quantum-core https://github.com/quantum-elixir/quantum-core ^ obviously it won't fit every use case (where you need 100% durability) but for that there's Oban which is awesome: https://getoban.pro https://getoban.pro

by grncdr 4y ago

quickthrower2 4y ago

What is presence awareness?

grncdr 4y ago
I will just steal the first paragraph from https://hexdocs.pm/phoenix/presence.html https://hexdocs.pm/phoenix/presence.html, but you can read much more about it there. > Phoenix Presence is a feature which allows you to register process information on a topic and replicate it transparently across a cluster. It's a combination of both a server-side and client-side library, which makes it simple to implement. A simple use-case would be showing which users are currently online in an application.
- quickthrower2 4y ago
  I see! Funny enough the app of the company I work for does this. The tech is simply running a stateful server behind the web server.

cpursley 4y ago

All those things you listed require additional background servers, redis, etc. In Elixir/Erlang, it's built into the runtime which is a huge advantage. And even with standard things like handling http requests in Elixir -absolutely smokes Ruby in terms of performance. This leads to real cost savings as well

silasb 4y ago
Those built-ins that you are talking about are not as well rounded as a dedicated framework. These built-ins operate at a different operating model than running additional background servers. This typically means that everyone in the org needs to be an Elixir/Erlang expert instead of having experts in Redis, cloud native, ... For better or worse, this is likely a large obstacle for many orgs. The argument for using Elixir/Erlang is also more difficult when you have large companies like Github and Shopify demonstrating that Ruby can scale. EDIT: Let's not forget that it's mostly the DB that slows CRUD apps down. Not the language or the framework.
grncdr 4y ago
No, they don't. You can absolutely run ActionCable with the postgres adapter in your main rails app server and require no additional services. Edit: this is also why I mentioned GoodJob, it supports the full ActiveJob API (delays, retries, etc), even comes with a nice Web UI, and it only requires Postgres.
- cpursley 4y ago
  I'm using Quantum as my job runner in Elixir. Doesn't require even Postgres. Can't do that in Rails or other stacks: https://github.com/quantum-elixir/quantum-core https://github.com/quantum-elixir/quantum-core ^ obviously it won't fit every use case (where you need 100% durability) but for that there's Oban which is awesome: https://getoban.pro https://getoban.pro