Open alabulei1 opened 1 year ago
Thanks for raising this. I made some comments below even though I'm not a dapr maintainer. While I work on wazero which is an alternative to wasmedge, I don't think the feedback is wazero specific. Hope it helps!
Does the project have any hard dependency on other technologies or cloud vendors? Example: Kubernetes, Azure, AWS, Terraform
Yes. This project depends on WasmEdge, a CNCF hosted WebAssembly runtime. The dependency is due to WasmEdge’s support for non-blocking networking sockets and the Rust tokio framework, which are crucial for efficient communications between the microservice and the sidecar.
Historically, dependencies that require CGO aren't actionable in dapr's main build. Since wasmedge requires native library installation on the host (accessed via CGO), this seems a non-starter even if it weren't also an interop issue.
Which programming languages will be used?
The Rust programming language will be used to develop the microservices. The compilation target of the Rust programs is wasm32-wasi.
A couple years ago, I think that a single language SDK of rust would make more sense. However, the primary programming language of Dapr is go. The current SDK is Go, and a wasm powered alternative should exist in Go source even if also in Rust or other languages like C. Late summer, Go supports WASI preview1 and TinyGo already does, so ruling in Go should be a requirement. This also reduces temptation to include non-standard crates or extensions to rust which only work with one runtime.
In other words, I think Go should be required as it not only allows a more fluid experience for maintainers and users, but it also avoids accidental lock-ins.
I'll stop at this, and in any case I think that end users (e.g. not second state employees or runtime authors like me) should pipe in about their experience and what they use it for. Ultimately things like this should be driven by users directly, especially since this is OSS.
My 2p!
Hi @codefromthecrypt
Thank you for the comments. However, the goal of this SDK is actually NOT to be part of the Dapr sidecar, which is where wazero fits in. 😂
Our goal is to have a SDK for microservices that utilize the Dapr sidecar. In another word, it is for microservice application developers who are Dapr users.
Here is a demo project that uses this SDK. It consists of 3 microservices to do image processing / AI inference etc, but utilizes the Dapr sidecar for service invocation and state management:
@juntao thanks for the clarification.. so, this is another sidecar that talks to the dapr sidecar. I think this image from https://github.com/second-state/dapr-sdk-wasi could be lifted into the description, especially as there has been talk about an actually embedded (e.g. living in sidecar) way to access the dapr SDK apis.
I'll bow out, as this seems more like an ecosystem branding thing (moving repo without affecting dapr in any way). Cheers!
Hi @codefromthecrypt ,
Thanks for the kind suggestions. I will add the image to the proposal. Thanks!
@yaron2 I have renamed the project for WasmEdge. Thanks.
Hi @alabulei1,
The Dapr STC has voted to approve this request for sandbox project. Congratulations. As a next step, we will create an org for you and invite you as a maintainer.
Hi @yaron2
Thanks. This is great news! We look forward to closer collaboration with the Dapr community!
Please let me know how I should proceed.
@alabulei1 apologies for the late response, you will receive a notification this week to be invited to the dapr-sandbox
org where you'll be able to move the SDK to. looking forward to it!
@alabulei1 apologies for the late response, you will receive a notification this week to be invited to the
dapr-sandbox
org where you'll be able to move the SDK to. looking forward to it!
Looking forward to it too!
What is the ETA to have this project reach a stable version and graduate to the main Dapr organization?
Who are the maintainers of this project and corresponding employers?