Chain multiple Workers/DOs with RPC stub forwarding across Service Bindings
I'm trying to achieve the most of the performance I can get by the ecosystem in a situation where I need to bounce a
request from an introduction worker to a deeply nested Service Binding DO in my architecture:
Until now I've been using HTTP across all services passing requests over the fetch() handler:
Introduction Worker (HTTP) -> Worker A (HTTP) -> Worker B (HTTP) -> Worker C (HTTP) -> Worker D (HTTP) -> DO (HTTP)
What I'd like achieve is switching to RPC for testing performance and speed:
Introduction Worker (HTTP) -> Worker A (RPC) -> Worker B (RPC) -> Worker C (RPC) -> Worker D (RPC) -> DO (RPC)
I'd also need to adopt a zero-copy strategy at step 1 (or all step if possible) and just stream it all over to Worker D where it's gonna be needed for processing for the first time.
According to docs an approach of such is possible with RPC since it supports both sending the whole Request as an argument as well as a ReadableStream but I'm unsure to the level of depth I can achieve, examples are few and only with 2 levels, also for ReadableStream there are no examples.
For the ReadableStream case is not clear if we're allowed to pass to a stub function an argument of { reader } and then at each nested level of depth, create a new couple of TransformStream to { write } to the received reader and pass the next { reader } deeper.
Same doubts about the Forwarding RPC stubs strategy, how deep can I chain them?
If anyone ever got to a situation of such can you please share your experience?
(I'm aware of the 1Mb limit for RPC, let's suppose the request is less than that)0 Replies