Request for new sandbox project: Project Leroy

[Haishi2016]

1. Describe how the Dapr community will benefit from this project? Please, describe one or more scenarios. Dapr delivers a set of capabilities, such as state and pub-sub, to app developers. Project Leroy expands on this idea and allow arbitrary capabilities to be registered, discovered, and consumed by applications. For example, an AI capability like "face detection" or "object tracking" can be registered and consumed as a capability. Leroy allows a developer to quickly evaluate and compare multiple vendors without heavy investment in specific technology during prototype and pilot phases. In production, Leroy is able to dynamically switch among compatible vendors based on runtime conditions as well as application constraints like connectivity, power consumption and performance envelope to help developers to write adaptative, resilient applications. Leroy natively supports Dapr, which means all existing Dapr capabilities work out-of-box with Leroy.

2. Which programming languages will be used?

   Leroy is written in Rust and is compiled into web assembly. Then, language bindings are created to provide language-native experiences. We currently have a Python binding, with plan to include JavaScript binding and C# binding in initial release.

3. Does the project have any hard dependency on other technologies or cloud vendors? Example: Kubernetes, Azure, AWS, Terraform

   No.

4. Enumerate the repositories this project will need to be created.

   The core source code of Leroy is in a single repository. There are two associated repository, one for a Leroy CLI tool, and another for a web-based playground for education purposes. However, they can be combined if easier for management.

5. What is the ETA to have this project reach a stable version and graduate to the main Dapr organization?

   We have a working prototype today with 450+ automated unit test cases. There are still a few features under development. The expectation is to have stable release by the end of 2022.

6. Who are the maintainers of this project and corresponding employers?

   Haishi Bai (@Haishi2016 ) from Microsoft.

[artursouza]

I support this project. I recommend having one repo for the core project and a separate one for the educational web UI.

[yaron2]

@Haishi2016 if developers today can consume this project via language specific bindings, why the need for Dapr? What's the tangible type of integration between the projects?

I don't believe the first question has been answered: "Describe how the Dapr community will benefit from this project?" I believe the answer here describes very well how developers benefit using Leroy.

Also, can you elaborate on what his means? Leroy natively supports Dapr, which means all existing Dapr capabilities work out-of-box with Leroy.

If there's already native support for Dapr in Leroy, why join it to the Dapr org? Dapr is natively supported by OpenFunction but the latter is not part of the Dapr org.

[yaron2]

Also, please provide STC members access to the project so we can perform due diligence. It's impossible to get an understanding of the project without access to the source code.

[Haishi2016]

@yaron2 Sure. I didn't expect STC members to be able to assess code quality telepathically :). I assumed it would be part of the process, but it hasn't been clear where this review process would have taken place. Please provide list of GitHub handles of STC members or point me to a place where I can see the list.

Dapr defines a set of APIs (or, capabilities). The idea of Leroy is to expand on this idea to allow new capabilities to be registered, discovered and consumed by developers. Because allow any capabilities to be registered and leveraged, Dapr capabilities are naturally supported. And this is why I think this might be a good place for Dapr sandbox, which I assume is to expand on Dapr ideas.

Consider a simple case - developer wants to choose a state store, but she has specific throughout requirements and licensing models in mind. How would she choose among the supported state stores? Leroy's semantic discover allows her to express such constraints and locate the right state store to use, and then Leroy can configure the Dapr sidecar, except for the secrets that are to be filled by operations.

[XavierGeerinck]

Is there a demo around this? Personally I find it quite vague description wise on what this delivers.

Is it delivering 2 things?

• dynamic component selection
• dynamic capability registration (extended binding support?)

But again I might be completely wrong in my understanding here

[Haishi2016]

Hi @XavierGeerinck, you are right, Leroy provides dynamic component selection as well as dynamic capability registration. You can use Leory as a library (think it as a Dapr SDK on steroid in this case), or you can use Leroy CLI separately just for component discovery.

For example, here's how you write Leroy code to publish to a topic, with a preference to use a pub-sub component with a local infrastructure, and the selected component must use MIT license, and must provide ensured delivery. Leroy can then check its connected repository and select appropriate Dapr component to use. Note that in production, you can configure Leroy to use a local, or enterprise-level registry so that you only choose from approved or pre-selected vendors. Let's say in your registry you have two pub-sub components, one is local (in a container, for instance), and one is on cloud. Leroy will use the local pub-sub channel (because it's preferred) but automatically falls back to the cloud channel if the primary fails (you can also attach different policies for failover as well).

publish("my-topic", my-payload) .prefer("location", "is", "local") .must("ensured-delivery", "is", true) .must("license", "is", "MIT")

Hope this helps.

[Haishi2016]

@yaron2 @msfussell @paulyuk @artursouza @beiwei30 @Forrest-zhao I've invited all of you to view the repo. Please let me know if you have any questions.

[Haishi2016]

Dapr provides abstractions of common capabilities like state management and pub-sub so that your applications are decoupled from the underlying dependencies. It allows technical decisions to be delayed to later phases of the project when requirements are clearer. It also allows you to switch to a different vendor as needed with your existing investments protected.

Leroy extends on this idea and allows any capabilities to be published, discovered, and consumed by applications. For example, “face detection” can be a capability published by a vendor. Through Leroy’s semantic discovery, an application can discover all vendors that offer the face detection capabilities and choose the ones it wants to use based on various constraints such as SLA, performance expectations, licensing model, cost, data sovereignty, model fairness across races, hardware requirements and many other factors.

Typical workflow:

1. A capability vendor registers a capability (such as "face detection") with Leroy's capability registry.
2. Using Leroy's CLI, a developer can discover capabilities with project constraints.
3. Leroy's CLI generates Dapr sidecar config with selected vendors.
4. Application interacts with Dapr side car to consume the capability, which is delivered through a Leroy binding.
5. Leroy binding works with a Leroy capability broker.
6. And the capability broker interacts with the selected vendor to deliver required capability.

[Haishi2016]

Closing this issue due to lack of interests. We no longer seek contributing Leroy to the Dapr project. Thank you.