It was quite a ride through the generics in this crate, but I finally found a solution for how to nicely decouple RPC services between modules or crates.
Importantly, it allows for an outer, app-level RPC service to delegate to inner services which are defined in other modules or crates. The inner services are regular quic-rpc services, and can even run on their own without the outer service. They take a single additional generic, so the code does not become horribly more generic.
See the modularize example for a full, end-to-end example that composes RPC services from two different modules (which could be crates as well).
Edit I found a new approach that allows to compose services not only for two layers but infinitely. I updated the modularize example to have an additonal layer:
App composes iroh and some app-owned RPC
iroh composes two other services, calc and clock
Note that the composition works equally for the server handler and a client wrapper. See the example.
It was quite a ride through the generics in this crate, but I finally found a solution for how to nicely decouple RPC services between modules or crates.
Importantly, it allows for an outer, app-level RPC service to delegate to inner services which are defined in other modules or crates. The inner services are regular quic-rpc services, and can even run on their own without the outer service. They take a single additional generic, so the code does not become horribly more generic.
See the
modularizeexample for a full, end-to-end example that composes RPC services from two different modules (which could be crates as well).Edit I found a new approach that allows to compose services not only for two layers but infinitely. I updated the modularize example to have an additonal layer:
irohand some app-owned RPCirohcomposes two other services,calcandclockNote that the composition works equally for the server handler and a client wrapper. See the example.