Open dinonuggies1 opened 3 years ago
linking a related issue to use ActiveSupport::Notifications.instrument
that would also have benefited from an around { ... }
hook: #49
What do you think of this design?
svc = Example::HelloWorldService.new(handler)
svc.before do |rack_env, env|
env[:beforefoo] = "bar"
end
svc.around do |s, env|
puts env[:beforefoo] # before hooks were called
s.call(env) # calls other around hooks, rpc call, and on_success or or_error hooks
env[:aroundfoo] = "bar"
puts env[:output] # object returned by rpc_call (env[:output_class] is also available)
puts env[:twirp_error] # if the output was an error, it is also included here
end
svc.on_success do |env|
puts env[:successfoo] # on_success and on_error hooks are called after around
end
Looks great!
The twirp-ruby package provides great out of the box hooks (
before
,on_success
,on_error
,exception_raised
) pre and post the twirp service handler invocation. For most cases, I believe this implementation contains the required functionality to augment the call for a given rpc method, but I have recently discovered a need to yield the execution of an rpc call with Twirp specific routing information.The Twirp wire protocol uses the POST request method for every rpc call. We have database middleware components in place that translates those Twirp POST request as requiring a :writing connection to the database, which may create unnecessary strain on our DB primaries, when in most cases, only a :reading connection is required, thereby hitting the replicas and reducing pressure on the primaries.
I'm looking for a way to wrap twirp handlers in read-only DB connections utilizing
ActiveRecord::Base.connected_to(role: :reading) { ... }
So far, I've managed to come up with an alternative solution by creating a module that selects the appropriate connection role given a list of rpc methods that require :writing connections. This module is then prepended to the
Twirp::Service
classWhile this accomplishes the functionality I need, it is certainly a bit of a hack.
I was wondering if there was a better/alternative solution that would be recommended to accomplish this task more optimally, or if you think this could be a great use case for an
around{ ... }
hook or a similar idea that would allow yielding execution of RPC methods with Twirp related information.