docs/adapters/custom/parallel-requests.md
!> This is slightly more involved, and this section is not fully formed.
Vague example, excerpted from the test suite about parallel requests
response_1 = nil
response_2 = nil
conn.in_parallel do
response_1 = conn.get('/about')
response_2 = conn.get('/products')
end
puts response_1.status
puts response_2.status
First, in your class definition, you can tell Faraday that your backend supports parallel operation:
class FlorpHttp < ::Faraday::Adapter
dependency do
require 'florp_http'
end
self.supports_parallel = true
end
Then, implement a method which returns a ParallelManager:
class FlorpHttp < ::Faraday::Adapter
dependency do
require 'florp_http'
end
self.supports_parallel = true
def self.setup_parallel_manager(_options = nil)
FlorpParallelManager.new # NB: we will need to define this
end
def call(env)
# NB: you can call `in_parallel?` here to check if the current request
# is part of a parallel batch. Useful if you need to collect all requests
# into the ParallelManager before running them.
end
end
class FlorpParallelManager
# The execute method will be passed the same block as `in_parallel`,
# so you can either collect the requests or just wrap them into a wrapper,
# depending on how your adapter works.
def execute(&block)
run_async(&block)
end
end
Prior to the introduction of the execute method, the ParallelManager was expected to implement a run method
and the execution of the block was done by the Faraday connection BEFORE calling that method.
This approach made the ParallelManager implementation harder and forced you to keep state around.
The new execute implementation allows to avoid this shortfall and support different flows.
As of Faraday 2.0, run is still supported in case execute is not implemented by the ParallelManager,
but this method should be considered deprecated.
For reference, please see an example using run from em-synchrony
and its ParallelManager implementation.