Continuations over binding Httphandlers (Breaking Change) about giraffe HOT 15 CLOSED

If I understand this correctly, an HttpHandler would behave like middleware?

IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)

from giraffe.

@JonCanning that's a nice way of thinking of it, micro middleware that is functional and extends the existing pipeline. I know it's preferable not to introduce an extra parameter but given it comes with many benefits (as outlined in my post), I'm hoping people may warm to it!?

from giraffe.

Actually, the second example in writing middleware in MS Docs is nearly identical to what I'm doing/proposing, cache a next delegate/function, call the function with a context. The only difference really is that we use an option to allow branching/choosing of multiple paths, If it wasn't for this branching requirement, you would just do a functional wrapper/compose for the requestDelegate and not even the change format, but as we know this is restrictive and takes away a lot of the benefit of being able to 'try' paths with fallbacks (like choose handler)

using Microsoft.AspNetCore.Http;
using System.Globalization;
using System.Threading.Tasks;

namespace Culture
{
    public class RequestCultureMiddleware
    {
        private readonly RequestDelegate _next;

        public RequestCultureMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public Task Invoke(HttpContext context)
        {
            var cultureQuery = context.Request.Query["culture"];
            if (!string.IsNullOrWhiteSpace(cultureQuery))
            {
                var culture = new CultureInfo(cultureQuery);

                CultureInfo.CurrentCulture = culture;
                CultureInfo.CurrentUICulture = culture;

            }

            // Call the next delegate/middleware in the pipeline
            return this._next(context);
        }
    }
}

from giraffe.

I had to write a middleware the other day since I wanted to execute the next delegate and do something afterwards, so I approve.

from giraffe.

There's that benefit too! I'm fully open to alternative implementations provided we can maintain the TCO & pass-through of tasks from child handlers to avoid wrapping sync in async.

My version with 3 parameters fun next fail ctx -> ... removes the need for an option, allows fail to jump right to finish/failover, all TCO, min stack frames, but is a bigger, more breaking change so getting the balance right is important.

from giraffe.

If I understood it all correctly, even though a breaking change, the difference is not huge in how someone would build and compose a web application, but with some great benefits overall. I think I am in favour of this change.

from giraffe.

I also referenced your blog post here.

from giraffe.

Is it easiest if I incorporate the task CE, next continuation together with the new router into my develop fork, few people can test and make sure comfortable, then merge? Do one big breaking change only?

from giraffe.

Hi @gerardtoconnor I think we should keep the task CE and the continuation changes as two separate PRs please. I think the continuation is a much less risky change than the task CE, which will require a lot less testing as well.

from giraffe.

Ok, So would you prefer I do continuation or task CE first?

On the task CE, I have found a way to allow overloading of both Task & Task<'T> without type assertions, using extension methods, should make the changeover more seamless.

I will leave the tree router in a 3rd, last PR then.

from giraffe.

I think the continuation could be a quicker gain, but what do you think?

from giraffe.

Well I think both are important for performance so both need to be done but I guess the continuation is little simpler, less breaking.

One of the reasons I wanted to do both together was to do just one big breaking change as doing two in close succession may be taxing on users, If we merge continuation with the Task CE to follow closely after, would be pointless for users to try upgrade till both are in ... I'm just thinking from users perspective?

I have both continuation & task CE updated in src of my gtoc-develop branch if you want to review, need to update test & sample proj still

from giraffe.

I agree with you, however the Task CE is a more complex change IMHO and I would want to test its perf impact more thoroughly before merging, while the continuation change I think of as an elegant architectural change with little risk.

from giraffe.

Cool, I'll rebase off current async branch and do contination PR in next day or so.

from giraffe.

PR added #71

from giraffe.