search

dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
10.12k stars 2.04k forks source link

Blazor WebAssembly support #8421

Open lostmsu opened 1 year ago

lostmsu commented 1 year ago

I am starting a decentralized project, and was wondering if it would make sense to use Orleans in it.

The system would consist of a diverse set of "server" nodes running .NET 6 on Windows, and "clients" would be written to run in browser using Blazor and WebAssembly. The server nodes would spin services for the clients. Potentially, clients themselves would spin up some other services for other clients to connect to.

Generally speaking I would connect clients to the closest idle server nodes that match some criteria specified by the client.

Because the clients will run in a web browser, the big question is: does Orleans support Blazor and WebAssembly, and can it be adapted to communicate over web sockets?

ReubenBond commented 1 year ago

Orleans is not intended to be used outside of the cloud (eg, on external clients). We recommend that you create a gateway using HTTP/gRPC/SignalR/etc and call into that from your clients.

lostmsu commented 1 year ago

Hi @ReubenBond can you clarify:

  1. What limits Orleans from running inside Blazor + WebAssembly (if anything)? Is it a lack of abstraction for transport layer and/or security layer?
  2. Re: intended. What makes Orleans unsuitable for use outside of cloud/private data center scenarios?
bxjg1987 commented 5 months ago

Perhaps it's a misunderstanding, I just want to run the orlean client in the blazer webassembly, not the grain.

0xF6 commented 1 month ago

It is strange that the Orleans client does not have an implementation for either warm or js 🤔

0xF6 commented 1 month ago

I have small research, need to change the logic of how ConfigUtilities::GetLocalIPAddress and orleans are launched in wasm, but of course a connection is not created, because tcp is missing in wasm\browser

In theory, if add a websocket transport, then everything maybe will work 🤔

0xF6 commented 1 month ago

So, I did a couple more research on rebuilding and adding websocket\webtransport (QUIC) transport We will have to modify Orleans.Client too much, alas Especially because of such things Image tcp is nailed down in many places, very sad 😢 I don't see any roadmap or timeline for the Orleans team, most likely alternative transport (including udp with delivery confirmation mode) will most likey not be implemented, ehh

ReubenBond commented 1 month ago

Web support in general is out-of-scope for Orleans because your silos should not be exposed to the Internet directly - having a custom gateway in-between is the common approach: eg, a REST or gRPC API.

That being said, I have been prototyping gRPC support for grains so that you can use .proto contracts on your grains and call them externally. Would that help in these situations?

0xF6 commented 1 month ago

@ReubenBond

Web support in general is out-of-scope for Orleans because your silos should not be exposed to the Internet directly - having a custom gateway in-between is the common approach: eg, a REST or gRPC API.

That being said, I have been prototyping gRPC support for grains so that you can use .proto contracts on your grains and call them externally. Would that help in these situations?

gRPC with proto is not a convenient protocol, it is too empty without convenient abstractions + in cases you often have to use a large and thick native library into the project, and C#'s proto compilation is a bit damp and call multiple pain 🤬

I mean, the Orleans team could also release an rpc with streaming client, because using interface-based contracts is a very convenient way to interact

anyway we have decided to use stl.fusion as an entry point for communication with Orleans 🫤