Orleans.AspNet

[creyke]

A similar issue (#2427) focuses on exposing Orleans over HTTP, however the proposal here is to make Orleans more accessible to standard .NET developers by providing the silo via an intermediary NuGet package which embeds Orleans into an existing ASP.NET project.

Some assumptions and opinions:

1. Microservices are becoming more popular and developers building them favour the simplicity of executing a single process (potentially in a container) which represents the application tier of their service.
2. The vast majority of .NET developers (a large potential customer base of Orleans) are familiar with the ASP.NET stack and develop stateless web application on it.
3. ASP.NET applications provide no consensus / clustering protocol out of the box, therefore state is usually held in the database, occasionally in memory, and sometimes in separate caching technologies.

The accessibility of Orleans is currently impeded (at least in part) by a non-trivial complexity in developing and orchestrating the solution behind HTTP endpoints remote from the silo.

Primarily the argument here is not so much a technical one, it's a proposal to open up a large market to Orleans, by enabling easy installation of the Orleans silo into an existing Asp.Net project.

This would be seen as "turbo charging" ASP.NET with features such as caching, streaming, and scheduling.

Example process:

1. Developer creates a new ASP.NET Web Application.
2. Developer installs the Orleans silo into it via Install-Package Orleans.AspNet
3. The Orleans.AspNet install script creates a default map of routes from ApiControllers to respective Orleans grain instances.
4. An example grain class is provided with an example controller method.

I can expand on the details of this, but initially I'm curious to see if there is an appetite / empathy with what I'm proposing and the challenges to adoption that I've felt while on-boarding this technology in a traditional Web API shop.

[jdom]

I believe enabling this thing is how we are actually approaching the HTTP endpoint story. @attilah has been prototyping a little bit, but the point is that we are preferring to open up opportunities to make it easy to queue grain calls to a local silo and so on from an existing asp.net app, as well as providing some scaffolding of routes to make it easy to get started. But with that, the user would be in full control, as opposed to the HTTP endpoint being a blackbox.

[creyke]

This could also provide a backplane implementation for SignalR Core out of the box, similar again to Richard Astbury's OrleansR...

To re-emphasise this would be as much a sales tactic as it is a technical enabler.

[creyke]

Was considering something like this: https://github.com/creyke/ToasterService/blob/master/ToasterService.Api/Controllers/ToasterController.cs

cc @attilah

[galvesribeiro]

Hey guys.

This is as up-for-grabs. Is @attilah really working on that? If not please let us know. I would like to pick that up for a try.

[creyke]

@galvesribeiro @attilah Here's an update to the proposed default project structure:
https://github.com/creyke/ToasterService/tree/master/ToasterService.Api

Note the lack of any secondary libraries, and the lack of code too required.

I would argue using stateless workers as entry point grains further simplifies the (initial!) bootstrap.

[galvesribeiro]

IMHO I would like to have an experience like this:

public class Startup
    {       
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddDbContext<TodoContext>(opt => opt.UseInMemoryDatabase());
            services.AddMvc();
            services.AddOrleansSilo(options => {
                        options.Configuration.Globals.RegisterBootstrapProvider(“MyProvider”);
                        // Register a route from a given Url template to a given grain method.
                        // This method don't require the user to implement a controller class
                        options.Routing.RegisterRoute<IMyGrain>(“/mygrain/{grainId}/{action}”);
                        // Register a grain type to a controller class. 
                        // That would allow the developer to have a more granular control about the controller class. The controller would inherit from an abstract `GrainControllerBase` or something, which would expose some facade on top of the Grain Client.
                        options.Routing.MapGrainToController<IGrainType, IControllerType>();
                   }
            );
        }

        public void Configure(IApplicationBuilder app)
        {
            app.UseMvc();
            app.UseOrleans(); //This will register Orleans client in ASP.Net DI stuff in case you need to create your controllers by hand, so it will inject Orleans client to it. It would also replace the Asp.Net `IRouter` default implementation with one we built, so we can map controller class to grain implementation.
        }
    }

The major thing here is that we need to have some sort of in-memory client that would talk to Gateway without use TCP locally.

I'll try to find some time to investigate further on that but looks to me that it would be best of our interest to keep an API somehow familiar to asp.net developers.