ASP.NET Core MVC/Web API support
Enable developers to create serverless applications using the ASP.NET Core Web API framework.
Great ask. Keep the votes coming. Nothing planned short term.
If i have project with web API asp.net core, And i want to use Azure function V2 (consumption plan).
I can create many function with an Http triggered or
I can create one Http Proxy function and refernce the same project i use today,
I think this is how Amazon is doing - it is the simplest way.
I found nice workaround here - https://blog.wille-zone.de/post/serverless-webapi-hosting-aspnetcore-webapi-in-azure-functions/
Simon Luckenuik commented
I will copy here some comments I made previously on GitHub (https://github.com/Azure/azure-functions-host/issues/2557) to provide some arguments in favor on that approach:
Using Azure Functions V2, I was able to have Razor Pages running properly inside a Functions host using the TestServer approach: http://www.luckenuik.net/hosting-your-aspnet-core-razor-pages-inside-azure-functions/
This is a proof of concept, but if we develop something similar to TestServer of production grade (and proper tooling to ease the job), we should be able to leverage the full power of MVC APIs\Pages inside Azure Functions.
I do understand that Azure Functions is meant to target multiple languages and that this is a .NET only approach, but I believe there is a need for such an approach. Obviously, something built-in Azure Functions would be preferable...
I know there are some people out there against running AspNet Core MVC inside Azure Functions, but the complete discussion around "it will take more memory, increase start-up time and adds overhead" is meaningless in my view, at least for some scenarios:
-Startup time: we are already facing Cold Starts today, that's not going away, adding few milliseconds to initialize the MVC stack is irrelevant. With Azure Functions Premium plan, these concerns will be less relevant, I guess.
-Execution Cost: No matter how much memory you are using, for some apps it is still cheaper than having an App Service running 24/7.
-Ramp-up Cost: It is way cheaper to take the existing knowledge of developers and make them code as usual with MVC Controllers instead of ramping-up with Azure Functions.
-Reuse Opportunity: A lot of work was done by different projects to increase the AspNet Core middleware with interesting features (Ex: Authn\Authz), it is a shame that we cannot reuse that work easily with Azure Functions.
-Complexity: If you want to run any business application on Azure Functions, you will face complex code that might take longer than 50 milliseconds. It's not true, in my view, that Azure Functions was designed for small projects only, with quick "in and out" only.
Lukas Kabrt commented
I would like to see this feature, because I want to run existing Web API application inside Azure Functions.
I have been able to archive this with the HTTP trigger and application hosted inside the Azure Functions (https://blog.kabrt.cz/posts/2018-11-serverless-asp-net-mvc). This solution "Works on my machine", but the approach seems little hacky and build-in support for such scenarios would be much better,
Simon Luckenuik commented
That would help minimize ramp-up time for developers coming from the Web API world.
This would also ease migration of some API based applications to Azure Functions.
Daniel Ferreira commented
GA time for Functions v2?
John Waters commented
EntityFrameworkCore support is a must
Markus Strobl commented
Easy Integration of OAuth/OIDC Middleware and declarative Authorization with Authorize Attributes would be my biggest wish here
Sipke Schoorstra commented
ModelBinding comes to mind. Especially custom model binders.
Someone wrote a blog about how to setup DI today in Functions: https://blog.mexia.com.au/dependency-injections-on-azure-functions-v2, maybe there could be "official" support for this, whatever that would mean.
I would very much like to see this support - being able to use the full depth of ASP.NET Core libraries and toolchain would be a vast improvement over the stunted and relatively poorly tooled HTTP request pipeline currently available on Azure Functions.
I would go as far as saying that this would be the major enabling feature for me to migrate major web service infrastructure to Azure functions.
Also, Amazon's already done it in Lambda: