Open sergeybykov opened 7 years ago
Although I'm still look for a future where the client protocol would be documented and open, this is definitively a very good starting point to remove the needless external client where it is just a HTTP endpoint forwarding requests to grains.
The endpoint controllers could be easily generated by codegen and spin up on silo startup as you mentioned.
For scenarios where streams or observers are required, some websocket (maybe SignalR) endpoint can be exposed as well.
+1
I agree that not having to go through a client could be advantage, also for performance (particularly response latency).
If the client is on the silo, it saves one hop. Also, silos are better equipped than clients: they have a grain directory cache, and they have a sophisticated scheduler.
When we did performance experiments for the planned reactivity support (project Bruges with @ticup) the response latency inside grains was much better than inside clients.
I think this is an exciting possibility.
Some thoughts:
Content-Accept
request header.@richorama I agree with most of your points.
Access control/Public/private endpoint - IMO we should make it all open and be very explicit in the docs that this is not for unsecured external exposure.
Bootstrap Provider - I think it will simplify many developers lives if the HTTP were enables by default, with no bootstrap provider, etc., and with an optional config piece to turn it off or customize parameters.
Websockets / WebRTC I would leave this out of scope for now.
I think we could cover all @richorama's points by just adding an ASP.Net WebAPI to Orleans and ask people to inject its settings on silo configuration somehow... Security, auth, cache, websocket, cors, encoding, etc... All those concerns are already solved by ASP.Net. All we need is have an endpoint that doesn't have to initialize GrainClient since it is inside the Silo. People can open it to the web behind a load balancer and roundrobin the load across the servers. Why do we need to reimplement that again?
That would also enable existing .NET Web API code bases to easily "upgrade" to Orleans.
@sergeybykov if you're able to advise me on the best place to add an HTTP endpoint (i.e. in terms of the project structure, and the best place to hook it into the silo startup sequence) I'll start work on a PR.
What @galvesribeiro @sebastianburckhardt mention is very interesting to me too but that is orthogonal to this feature I guess.
If we can open up silos by having interceptors for access control then it is great, maybe RPC framework of Bond can help us as well specially if they support AOT as well in the future but that is a different story.
To me the only functionality of a front-end is at the moment to provide access control and security and in case of socket based ones, connect and disconnect events. If we can make these available in our silos then it would be awesome. Currently I spend 30% of my time writing the front-end and its tests.
But again it has nothing to do with this feature or its usefulness. This feature even doesn't have to become fast or use codegen or whatever, the current thing is good good for the scenarios mentioned IMHO.
@sergeybykov if you're able to advise me on the best place to add an HTTP endpoint (i.e. in terms of the project structure, and the best place to hook it into the silo startup sequence) I'll start work on a PR.
I think we could have a class inside OrleansRuntime.dll
that would get instantiated at the end of silo initialization (unless turned off in config) and injected with references to InsideRuntimeClient.GrainFactory
, OrleansTaskScheduler
and a scheduling context (we can probably start with Catalog.SchedulingContext
and replace it with a dedicated system target later).
After receiving and parsing a web API request, the class would do scheduler.QueueAction(action, schedulingContext).Ignore();
where action
is a closure with GrainFactory.GetGrain<interface>(key);
invocation of the grain method, awating it, and producing and returning a response to the web call.
As per my previous comment, as a consumer, I would strongly recommend this is sold and crafted as Orleans in ASP.NET rather than HTTP in Orleans.
There are a huge number of potential users of Orleans (currently on ASP.NET and ASP.NET Core) who would take note of it's capabilities if they could just add Orleans.ASP to their existing Web API and MVC projects.
Raised as a separate issue as it's a separate proposal.
Adding an embedded HTTP endpoint similar to https://github.com/OrleansContrib/OrleansHttp to silo code I think would bring several benefits.
GrainClient
for testing simple enough scenarios.ManagementGrain
by not requiring a client app likeOrleansManager
. This could be leveraged for managing or troubleshooting production deployments by remoting into the cluster or accessing the internal HTTP endpoint some other way.Looking at
OrleansHttp
, my impression is it could be used almost as-is if we remove the need for a bootstrap provider, and instead initialize the endpoint as part of the silo startup sequence.