Akka HTTP in .NET land

[rogeralsing]

In .NET we do have both Web API, NancyFx and some built in support for Http in .NET itself. if/when we start to port Akka.HTTP to .NET. should we really intorduce yet a new layer of Response / status codes etc? or is it possible to base our work ontop of one of the existing solutions out there?

Should we just blindly stick to the JVM implementation even if there are established libraries for some of the infrastructure that we will need?

[Aaronontheweb]

What does the akka-http package add that Nancy et al do not? Is there just some custom API scheme on top of actors?

[rogeralsing]

Akka HTTP is like an actor based NancyFx.

So instead of building a Nancy module which handles different incoming Http requests, you create an actor that gets Get/Post/Put messages and pattern match on the URL passed in those messages.

But as I see it, it would be almost as easy to just spin up a self hosting Nancy module and just pipe incoming requests into actors.

[Horusiath]

If I remember correctly, in scala, akka-http has it's own unique API over HTTP primitives that are designed to be type safe in mind. I'm big fan of that. Also this is only some boilerplate code (guess with R# support half of it could be generated), while API separation gives us much more freedom.

@Aaronontheweb Akka.Http is designed to work with actor's from end-to-end. 2.0 version is supposed to work using reactive streams, with things such as backpressure etc. AFAIK there are plans for the future to integrate it with browser frontend, so that you could possibly move actor system boundary even further, on client machine.

[fergusn]

Look at the Akka HTTP stack on https://twitter.com/typesafe/status/610852728206659584/photo/1.

There are a lot of advantages of having the full stack in Akka. I also like the idea that I can go up/down the stack depending on my requirements, and get a similar API, e.g. I'm currently building a solution that multiplex several connections, using different higher level protocols, over a single TCP connection. Using the same base layers in this use case is required.

Using existing abstractions for the HTTP model means taking an additional dependency for little value. As @Horusiath suggested, defining the HTTP model is trivial and it (almost) never change. An dependency will cause more issues imo.

The other use case is to run existing frameworks (e.g Web API and Nancy) on top of a Akka HTTP server - this could be supported by creating a OWIN adapter.

[bobanco]

@willieferguson i agree with you, there are a lot of benefits to have Akka HTTP in .NET land, it could help us building more scalable HTTP API services using the actor model from the base to the top of the service implementation.

[rogeralsing]

OK, I'm closing this, I just wanted to get some overview of what others thought. Just so we dont start an effort that is already solved by existing .NET tools.

[Schandlich]

I will say this, after moving from .NET to Java and being thrown into Akka at the same time; akka-http's syntax is just awful compared to any Sinatra based frameworks (Nancy, Spark). It is nice how easily and well it integrates with Akka as a whole, but simple things like routing and parameter parsing are just a pain in the butt. I am honestly just using it now because Play makes me want to poke my eyes out with a rusty spork.

If you have any wiggle room in the port of it, I would love to see these issues addressed.

[rogeralsing]

This is exactly what I was afraid of, that the Akka Http API would feel awkward and that we might have something more mature in .NET already. I'm personally a fan of Nancy. @Schandlich is it how you handle messages in Akka.Http that is the main problem? that you cant express things like routes with dynamic args?

Maybe a special type of actor with an API similar to Nancy would be better? Thoughts?

[Schandlich]

@rogeralsing The lack of documentation may be skewing my thoughts on it right now, but it just feels like this is waaaaaaaaaaaay too much.

    @Override
    public Route createRoute() {
        return route(pathPrefix("v1").route(getApples(), pathPrefix("v1").route(getOranges(), pathPrefix("v1").route(getGrapes()));
    }

    private Route getApples() {
        return path("patients").route(get(handleWith((ctx) -> {
            return handleGetApplesRequest(ctx);
        })));
    }

    private Route getOranges() {
        return path("patients").route(get(handleWith((ctx) -> {
            return handleGetOrangesRequest(ctx);
        })));
    }

    private Route getGrapes() {
        return path("patients").route(get(handleWith((ctx) -> {
            return handleGetGrapesRequest(ctx);
        })));
    }

    private RouteResult handleGetApplesRequest(final RequestContext ctx) {
    }

    private RouteResult handleGetOrangesRequest(final RequestContext ctx) {
    }

    private RouteResult handleGetGrapesRequest(final RequestContext ctx) {
    }

From what I can tell, I don't see anything really special that akka-http does that any framework that is hosted on top of Netty couldn't do. They can still join the cluster, they can still create an actor per request, they still use Asks.

I would rather just see examples in Nancy, ASP.NET Next, and WebApi w/ Owin hosted in Topshelf so that I could be confident that I am doing it right. (The latter of which I feel probably fits in the most with the PetaBridge examples I see.)

TL:DR I would provide examples of how to use Akka.NET in Nancy, WebApi w/Owin, and ASP.NET Next instead of creating an entire new framework.

[fergusn]

In terms of the OWIN actors (http://owin.org/spec/spec/owin-1.0.0.html) Nancy is a Web Framework. I see the role of Akka HTTP Core more as a low level library to implement a Server.

Having a low level HTTP API to build a Server has many use cases, e.g.:

1. Implement the TLS SNI extension, which is not supported in HttpListener afaik
2. HTTP pipelining (support in HttpListener unknown)
3. Handle back pressure
4. Upgrade protocols: I use it to upgrade to STOMP for example
5. Same server on all platforms (HttpListener uses http.sys on Windows)

I built an HTTP Server on Akka IO which has an adapter to dispatch requests to an OWIN pipeline, but can also handle more advance use cases - HTTP Upgrade and back pressure in my case.