Matheus Cumpian

Answering my own question now that I've been working for a month or two with Rails.

Rails folks usually rely on background jobs to work with concurrency. If you need to send a couple of HTTP requests that can be done in parallel, no problem, you can use the asynchronous functionalities of Ruby 3+ to deal with it. Otherwise, anything compute intensive or that will deal with heavy I/O you'll send it to Sidekiq or something like that to be processed in workers, because you don't want to starve the threads of your main puma server with these kind of load.

Hope newcomers from other languages can benefit from this learning.

Hi everyone, how’s it going? I’m a Go developer transitioning to Ruby due to a job change. Typically, I solve various problems in web apps using Go’s lightweight threads (goroutines). For example, if I have two operations that involve I/O, I usually launch them in goroutines and wait for their responses. In short, there are countless situations where I use concurrency to tackle different types of problems. I’ve been studying a bit and saw that there are several ways to handle concurrency in Ruby, including a well-known library. However, I would like to know if there’s a “typical” way to handle concurrency within Rails. How do you usually deal with this?