Can Azure Function Replace Web API

A few days ago, I effectively migrated an ASP.NET Core Web API project to Azure Function, thereby taking benefit of the serverless functions of the Azure platform to lessen operation and upkeep expenses with the aid of using 10 times. This article will introduce the important thing steps and practices withinside the migration technique that will help you understand the Migration concepts.

Why the Serverless - Azure function?

Azure Functions is a serverless compute service and straightforward solution for running small pieces of code, or "functions," within the cloud. It can make our development even more productive. You'll write just the code you would like for the matter at hand, without fear of the whole application or the infrastructure to run it.

Code Difference

Finally, on the thing that .NET programmers are most interested in, what is the difference between the function code and the original Web API code? First of all, you don't need Program.cs anymore, Startup.cs, Controller is gone too, appsettings.json is gone too, now it's just your business code. Now my app layer has only one class, the logic is very similar to the original web API controller.

HTTP Trigger Function == Web API Action

// ASP.NET Web API
// Endpoint URL: /products/{id}
[Route("products/{id}")]
[HttpGet]
public async Task < IActionResult > GetProduct(int id) {
    // Handle HTTP Request Headers
    // Handle HTTP Request Message
    // Return HTTP Response
    var msg = new {
        Id = id, Message = "Hello World"
    };
    return Ok(msg);
}
// Azure Functions HTTP Trigger
// Endpoint URL: /api/products/{id}
public static async Task < HttpResponseMessage > Run(HttpRequestMessage req, int id, TraceWriter log) {
    // Handle HTTP Request Headers
    // Handle HTTP Request Message
    // Return HTTP Response
    var msg = new {
        Id = id, Message = "Hello World"
    };
    return req.CreateResponse(HttpStatusCode.OK, msg);
}

There are some major differences we should know before migration:

Azure Functions are always static methods

Even though Azure Functions are extensions of Azure WebJobs, every characteristic has a static modifier with the aid of using design, in contrast to Azure WebJobs maybe without the static modifier.
Actions of Web API, with the aid of using the way, don’t have the static modifier. This outcome in a good-sized architectural extrude at some stage in the migration, specifically with dependency injection (DI). We will contact it later.

Azure Functions always obtain the HttpRequestMessage example as a parameter

Within the HTTP request/reaction pipeline, a Web API controller internally creates an HttpContext example to deal with information like headers, cookies, sessions, query strings, and request frame (of path query strings and request frame may be treated in a one of a kind way). The HttpContext example works as an inner asset so any motion can at once get entry to it. As a result, every motion best passes essential info as its parameters.

On the opposite hand, every characteristic takes a one-of-a-kind HTTP request/reaction pipeline from Web API, which passes the HttpRequestMessage example to the characteristic as a parameter. The HttpRequestMessage example best handles headers, query strings, and request frames. It doesn’t appear after cookies or sessions. This is the big distinction between Web API and Azure Functions in phrases of stateless.

Functions should consider service locator patterns for dependency management

There are many appropriate IoC field libraries for Web API to control dependencies. However, we've already mentioned in my preceding post, Managing Dependencies in Azure Functions, that Service Locator Pattern has to be taken into consideration for DI in Azure Functions, and in fact, that is the handiest manner to address dependencies for now. This is due to the fact each Azure Function has a static modifier which prevents us from the usage of the identical manner as the only in Web API. We realize special critiques towards carrier locator styles for Azure Functions exist out there, however that is past our topic, so we are able to speak about it later in some other post.

For reference - How to use Dependency injection and Crud Operations using Azure Function with .Net Core, Do check my another article here

Conclusion

Migrating from a simple web API that has little commercial pressure to Azure Function can save significant development and operational costs. By using the serverless platform, we can focus on the business logic itself rather than the infrastructure code. We can continue to use the programming language we know while maintaining some flexibility and security.

Keep learning !!!