Clarifying adapter usage vs "plain Async"

[balvig]

Sorry to use GitHub issues for a question (happy to turn this into a documentation PR if applicable!), but I'm struggling to understand the difference between using this adapter with Faraday, vs using "plain" https://github.com/socketry/async with Faraday.

The in_parallel documentation shows the following example:

Async do
  response1 = Async{adapter.get("/index")}
  response2 = Async{adapter.get("/index")}
  response3 = Async{adapter.get("/index")}
  
  puts response1.wait.body # => "Hello World"
  puts response2.wait.body # => "Hello World"
  puts response3.wait.body # => "Hello World"
end

I'm having trouble understanding how this relates to the faraday adapter and what the difference is from using just https://github.com/socketry/async?

Put differently, what is the difference between these three examples?

1. Set default_adapter to async_http

Faraday.default_adapter = :async_http

response1 = adapter.get("/index")
response2 = adapter.get("/index")

puts response1.body
puts response2.body

2. Set default_adapter to async_http + use Async block

Faraday.default_adapter = :async_http

Async do
  response1 = Async{adapter.get("/index")}
  response2 = Async{adapter.get("/index")}

  puts response1.wait.body
  puts response2.wait.body
end

3. Use regular default_adapter + use Async block

Async do
  response1 = Async{adapter.get("/index")}
  response2 = Async{adapter.get("/index")}

  puts response1.wait.body
  puts response2.wait.body
end

[ioquatix]

Thanks for the question! Here's how these approaches differ:

1. Using async_http as the Faraday adapter, without an Async block

Faraday.default_adapter = :async_http

response1 = adapter.get("/index")
response2 = adapter.get("/index")

puts response1.body
puts response2.body

Each request happens one after the other, and the adapter sets up its own reactor for every request. This means you’re not getting concurrency or persistent connections. Even though you’re using the async adapter, it’s essentially behaving synchronously.

2. Using async_http inside an Async block

Faraday.default_adapter = :async_http

Async do
  response1 = Async{adapter.get("/index")}
  response2 = Async{adapter.get("/index")}

  puts response1.wait.body
  puts response2.wait.body
end

Now you get actual concurrency. Both requests run as fibers in the same event loop, sharing connections. This enables persistent connections and, if the server supports it, HTTP/2 multiplexing. This is where the async_http adapter shines.

3. Using net_http (or another regular adapter) inside an Async block

Async do
  response1 = Async{adapter.get("/index")}
  response2 = Async{adapter.get("/index")}

  puts response1.wait.body
  puts response2.wait.body
end

With Ruby’s fiber scheduler, Net::HTTP will release control while waiting for IO, so you get concurrency at the fiber level. However, you don’t get persistent connections, advanced connection pooling, or HTTP/2 support. Each request might open a new connection.

---

• The real benefit of async-http-faraday is persistent connections and HTTP/2 multiplexing, especially when used inside an Async block.
• Using a regular adapter with a fiber scheduler does provide concurrency, but without those advanced features.

Hope that clears it up!

[balvig]

Fantastic, thanks so much @ioquatix!
That really cleared things up for me 🙏