[scapegoat2]

I would definitely not call serving HTML from Azure Functions next-gen.

You are increasing the response time by 20-30ms just by using HTTP-Functions instead of plain ASP.NET (lots of abstractions and grpc channel to worker processes). Beyond that you will get long cold starts, no response-streaming and slow scaling. The cost of the consumption-based plan will skyrocket after small number of requests compared to serving from dedicated App Service.

[bob1029]

We are running on a dedicated/isolated (ASEv3) plan right now. It's incredibly fast & responsive. You can run a SSR web app directly on top of this kind of configuration no problem.

I am not sure what you are referring to with GRPC channels and worker processes.

[mwcampbell]

Since you're using Azure App Service Environment anyway, why bend Azure Functions to fit your web application use case rather than simply deploying ASP.NET Core on Azure App Service?

[bob1029]

> why bend Azure Functions to fit your web application use case

Because it is even simpler than screwing with ASP.NET Core if all you need is a simple SSR webforms experience (which I'd argue is most of us). I don't even have to worry about a startup.cs file or play games with the types of serializer or pipeline features I want to use. The only thing I have to do is take a http trigger method dep on ClaimsPrincipal and turn on AAD auth in the portal to get all my hard shit taken care of.

Why not return final text/html from a function that would otherwise return application/json to some cartoonish client-side complexity? Why add some API/web proxy middleware bullshit that serves no value? I am not buying the narrative anymore. This works, it is simple, it is fast. HTTP in, HTTP out. Microsoft would have to go so far out of their way to make this not work that it would look absolutely comical. "text/html is banned return content type because we are capricious assholes".