Affected project(s)
Is your feature request related to a problem? Please describe.
Seamless distributed networking is a magical aspect of wasmCloud. In distributed systems, magic is a little scarier than it is desirable.
If you bring a component to wasmCloud that imports wasi:keyvalue, your component call is automatically transformed into a distributed NATS request via wRPC. So, instead of a nanosecond in-process call to a host function, it’s subject to transport failure, message loss—all kinds of different issues. Introducing wrpc:error support in our interfaces is key evidence of this, as it provides runtime-level error handling of these transport errors.
To be clear, component networking via wRPC is a superpower of wasmCloud’s distributed model, but it should be used intentionally rather than implicitly.
Describe the solution you'd like
The distributed-by-default nature of wasmCloud is a superpower and a huge responsibility. It implicitly ties Wasm component invocation semantics with NATS core request/reply + queue group semantics, which is either awesome or frustrating for users.
I would like to lean further into our capability to inspect Wasm components and determine the correct course for an invocation. In combination with #4637, try to avoid going over a distributed network where possible by making proper scheduling decisions and explicitly decide when to make a distributed component-to-component call by using a specific interface built for that. This will lead to more predictable and reliable workloads.
Describe alternatives you've considered
I'd like to see one of a few things happen:
- Support distributed networking only in the case where there isn't a component running locally to satisfy an interface
- Support distributed networking only when an interface specifically is designed with a function type of
result<_, wrpc:error> so that components can handle fallible network requests
- Require component-to-component distributed calls to happen with a specific interface, e.g.
wasmcloud:messaging, that's designed for fallible networks and has its own messaging semantics
Additional context
https://wasmcloud.com/blog/charting-the-next-steps-for-wasmcloud/#host-responsibilities
This issue comes from many of our platform engineer users who want to design a system for wasmCloud where component function calls can be handled without panics in the case of a distributed call. wrpc:error as an error type that can handle these issues is in the right direction, but before that it essentially required using wasi:http or wasmcloud:messaging instead of the component wRPC calls to handle errors.
Affected project(s)
Is your feature request related to a problem? Please describe.
Seamless distributed networking is a magical aspect of wasmCloud. In distributed systems, magic is a little scarier than it is desirable.
If you bring a component to wasmCloud that imports wasi:keyvalue, your component call is automatically transformed into a distributed NATS request via wRPC. So, instead of a nanosecond in-process call to a host function, it’s subject to transport failure, message loss—all kinds of different issues. Introducing wrpc:error support in our interfaces is key evidence of this, as it provides runtime-level error handling of these transport errors.
To be clear, component networking via wRPC is a superpower of wasmCloud’s distributed model, but it should be used intentionally rather than implicitly.
Describe the solution you'd like
The distributed-by-default nature of wasmCloud is a superpower and a huge responsibility. It implicitly ties Wasm component invocation semantics with NATS core request/reply + queue group semantics, which is either awesome or frustrating for users.
I would like to lean further into our capability to inspect Wasm components and determine the correct course for an invocation. In combination with #4637, try to avoid going over a distributed network where possible by making proper scheduling decisions and explicitly decide when to make a distributed component-to-component call by using a specific interface built for that. This will lead to more predictable and reliable workloads.
Describe alternatives you've considered
I'd like to see one of a few things happen:
result<_, wrpc:error>so that components can handle fallible network requestswasmcloud:messaging, that's designed for fallible networks and has its own messaging semanticsAdditional context
https://wasmcloud.com/blog/charting-the-next-steps-for-wasmcloud/#host-responsibilities
This issue comes from many of our platform engineer users who want to design a system for wasmCloud where component function calls can be handled without panics in the case of a distributed call.
wrpc:erroras an error type that can handle these issues is in the right direction, but before that it essentially required usingwasi:httporwasmcloud:messaginginstead of the component wRPC calls to handle errors.