Tracking ASP.NET

[iancooper]

We've always sought to be accessible to ASP.NET developers and consciously our handler + attributes model was intended to be familiar. We use hostbuilder and now their logger.

But ASP.NET is changing, picking up an inline syntax that we don't have.

It's worth thinking about how we might support this alongside. Like most "DSLs" I'd like to have this layer over our push/ button API (today's) as it's mostly syntactic sugar.

But we don't want to fall too far behind idiomatically

https://twitter.com/davidfowl/status/1385290460613144577?s=21

https://twitter.com/davidfowl/status/1385323241028218884?s=21

[preardon]

Are you thinking about using this style for commands and events?

[iancooper]

Nothing concrete, just discussing ideas.

We would be unlikely to shift to a record type before .NET 6 as that is the next LTS release and I would rather target that for picking up any language changes etc on the LTS releases.

it's actually more the short way of writing a handler. I am assuming they are using code generation here to wrap your handler method in the controller invisibly. I like that because it means the underlying code is still the same, it's just removes the boilerplate. As much of our handler is boilerplate class definition, if you could just implement the methods and we could then generate the wrapping class, registration etc. that would give you a very 'clean' syntax, whilst still being compatible with the class hierarchy we have today.

If my guess as to what they are doing is right, it's different to say Carter or Mass Transit in that the final code is the same, you just don't need to hand-write most of it. I think that works well for me.

[preardon]

@iancooper definitely something I'de be interested in Discussing and working on

[iancooper]

So it feels like an equivalent for us would be:

var app = Brighter.CreateDispatcher(args); 

Action<MyCommand> writeGreeting = (c) => { Console.WriteLine{$"Hello {c.Name} }};

app.MapHandle<MyCommand>(writeGreeting);

//presumably app.HandleFallback etc.

await app.RunAsync()

and to be clear:

• The top level objects here wrap our builders etc. i.e this is how you configure and construct a dispatcher
• I assume we use Roslyn code generators or similar to create actual classes with these Handle methods, over dispatching to actual delegates

What we need to see how they handle is things like filters, so we can figure out what idiom to mirror.

Note, I can figure out ways to handle filters, but our goal is to be close in 'feel' to an ASP.NET app for a user

[iancooper]

BTW a lot of folks calling out Node as the influence here, but I think this is just modern web server style, Go is similar.

[iancooper]

OK, this issue is much clearer at defining the ASP.NET team's goals:

dotnet/aspnetcore#30580

[iancooper]

I'd completely missed this language feature, which allows C# to stand-alone functions:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-static

[iancooper]

And it's not, as I first suspected, some compiler trick, it's a lightweight alternative to using MVC

https://twitter.com/davidfowl/status/1388294426225643520?s=21

So that is more of a question for us. I think it's possible to align the stacks, just treat the delegate with a signature as an alternative to a RequestHandler, but it's worth noting the goal here from them is simplicity i.e. no filters etc.

It might also mean we want to map in-process and out of process through a top-level dispatcher.

So the goal here would be 'simple Brighter'

[iancooper]

This is much more what I was thinking we would do:

https://github.com/davidfowl/uController/tree/81b648ef46c11f09f878148f09618d3d332e0d9b