[rco8786]

I honestly feel like you're responding to an entirely different person, despite the fact that you quoted my post.

Rails can scale horizontally just fine for a huge, huge majority of business cases. If you have a business critical use case that truly needs however many thousands of things done in a tight loop inside a single process...obviously Rails is not the tool you should be using.

I did not say "the ability to optimize something is a trivial niceity". I said "concurrency often gets in the way more than it helps unless you're trying to optimize something". I'm not sure if you're purposefully misrepresenting my words, but it does feel like you are especially given the "so you never make HTTP requests" comment you started this thread with.

[jupp0r]

I also have the feeling that you are talking to a different person. I'm talking about latency, you are talking about bandwidth. I'm talking about concurrency, you are talking about parallelism.

You can scale up any Rails app super easily by throwing money at the problem, it's trivial. When a single page load or API request to it takes 20 seconds, it doesn't help you if you have 1000 servers that can respond to hundreds of requests in 20 seconds each, when you need that request served in 500ms. This means that while serving a single request you might need to do things concurrently (like make an http request to an authz service and do a db query at the same time).

[rco8786]

The amount of APIs in the world that require concurrency within a single request scope to meet latency needs approaches zero.

In practice, you don’t make that db call until the auth request is done and the user is verified. In practice, you don’t make the outgoing api call until you already have the results of the db call, because you need your data to form the outgoing request. Etc.

APIs where intra request concurrency is needed absolutely exist. But they’re the exception not the rule, even at large scale tech co’s. And yes. Rails is a bad choice for those.

[jupp0r]

"The amount of APIs in the world that require concurrency within a single request scope to meet latency needs approaches zero."

I've never worked on any non-Rails API where this was true. The Ruby community keeps telling me this, but in languages where concurrency is well supported, it gets used everywhere to a great extent. I obviously don't have hard data to support this, but your claim seems pretty far fetched to be honest.

"In practice, you don’t make that db call until the auth request is done and the user is verified"

Of course you optimistically do any idempotent DB operations while waiting for auth to succeed if you care about latency.

"you don’t make the outgoing api call until you already have the results of the db call, because you need your data to form the outgoing request"

These dependencies of course exist, but so do parts of the graph where they do not. You might want to make 2 or 5 outgoing calls based on your DB query and have to wait for 2 out of these 5 to make another DB query. This is so common that there are libraries like https://github.com/uber-go/cff to explicitly model those dependency graphs, visualize them and resolve them at runtime.

My theory is that system designs like this are just impractical to implement inside Rails today, which leads heavily Rails biased engineers to not even consider them, which leads Rails experienced developers to never have seen them, which in turn fuels the sentiment that they are rare. I'm not saying that you fall into this category, but from my experience many engineers who have only ever done Rails in their career do.