Embed an HTTP endpoint into silos

[sergeybykov]

Adding an embedded HTTP endpoint similar to https://github.com/OrleansContrib/OrleansHttp to silo code I think would bring several benefits.

• Simplify learning Orleans, as a separate frontend layer won't be required for invoking a grain from a browser or another app.
• Simplify local development by not requiring a GrainClient for testing simple enough scenarios.
• Simplify access to ManagementGrain by not requiring a client app like OrleansManager. This could be leveraged for managing or troubleshooting production deployments by remoting into the cluster or accessing the internal HTTP endpoint some other way.
• The endpoint could be exposed to the internet via a TLS-secured façade.
• For certain applications exposing the built-in HTTP endpoint via a load balancer may be sufficient without a separate frontend layer.

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.

[galvesribeiro]

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.

[creyke]

+1

[sebastianburckhardt]

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.

[richorama]

I think this is an exciting possibility.

Some thoughts:

• URI scheme. It's important to get the URI scheme right. I don't think OrleansHttp quite got it right with regard to compound keys. You should also be able to put parameters in the body of an HTTP POST to enable larger variable values.
• Performance. I think performance is a second order problem, I'm fairly certain that the clever people in the community will find a way for it to go fast. (perhaps using libuv???).
• Encodings. OrleansHttp uses JSON, but additional encodings (XML?) could be added later by observing the Content-Accept request header.
• Access control. Should all grains be addressable via HTTP? Should there be an opt-in / opt-out mechanism for grain types/methods? Should it go down to an individual activation level? Should there be authentication/authorisation, cookies and sessions? I think this opens a can of worms and the API should have the opinion that everything is open, and if you want to introduce an access control policy, you do that in your own web controller in an ASP.NET application that fronts Orleans.
• Public/private endpoint. I have a concern that people will attach this API to a public IP address and build client applications that connect directly. I think there is a huge amount to consider to enable this scenario which would massively increase the complexity. For example, repeated calls to the management grain to start a GC which expires all grains would be a great way to DDoS Orleans (see access control). The documentation should stress that the API is for internal consumption only.
• Bootstrap Provider. I'm not opposed to the idea of keeping it as a bootstrap provider. It makes it easy to turn on/off and configure.
• Discovery. It would be nice to have an HTTP endpoint which gives you an overview of the API surface available. I propose that an auto-generated swagger definition is considered, it seems to be the way to document HTTP APIs.
• CORS. It would be nice if you could configure CORS origin headers in the API. This would enable browser based apps (like a dashboard!) to connect to the API without having the file served from that origin.
• Websockets / WebRTC. I don't think websockets make a great API (personally). But if they're being considered, then the WebRTC RTCDataChannel should be in the mix too :¬)

[sergeybykov]

@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.

[galvesribeiro]

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?

[creyke]

That would also enable existing .NET Web API code bases to easily "upgrade" to Orleans.

[richorama]

@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.

[ashkan-saeedi-mazdeh]

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]

@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.

[creyke]

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.

[creyke]

Raised as a separate issue as it's a separate proposal.