TechiesWeb.NET

Durable AI Agent Workflows on Azure Functions

Sun, 12 Apr 2026 07:00:00 +0000

The Microsoft Agent Framework is an open-source, multi-language framework for building, orchestrating, and deploying AI agents. It provides a workflow programming model for composing AI agents and other units of work into multi-step pipelines. To make these workflows stateful, long-running, and fault-tolerant, the Azure Functions hosting package (Microsoft.Agents.AI.Hosting.AzureFunctions) can be used, which builds on the core Durable Task extension (Microsoft.Agents.AI.DurableTask) to host workflows on Azure Functions with automatic durability.

This post walks through building durable workflows and hosting them on Azure Functions. Starting with a minimal workflow, it progressively adds parallel execution, human-in-the-loop approvals, and MCP tool integration.

Why Durable Workflows?

AI agents are powerful on their own, but real-world scenarios often require orchestrating multiple agents together with branching logic, parallel processing, human approval gates, and the ability to survive failures and restarts. That’s where durable workflows come in.

Durable workflows are powered by the Durable Task technology stack, which provides:

Stateful, durable execution - workflows survive process restarts and failures
Automatic checkpointing - progress is saved after each step
Long-running orchestrations - workflows can run for minutes, hours, or even days
Observability - built-in tools for monitoring and managing workflow executions

The Workflow Programming Model

Before hosting anything, here are the core building blocks of a MAF workflow.

Executors

An Executor is the fundamental unit of work. It receives a typed message, processes it, and optionally produces output. Think of it as a single step in your pipeline.

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup() : Executor<string, Order>("OrderLookup")
{
    public override async ValueTask<Order> HandleAsync(
        string message, IWorkflowContext context, CancellationToken cancellationToken = default)
    {
        // Simulate looking up an order by ID
        return new Order(
            Id: message,
            OrderDate: DateTime.UtcNow.AddDays(-1),
            IsCancelled: false,
            Customer: new Customer(Name: "Jerry", Email: "jerry@example.com"));
    }
}

internal sealed class OrderCancel() : Executor<Order, Order>("OrderCancel")
{
    public override async ValueTask<Order> HandleAsync(
        Order message, IWorkflowContext context, CancellationToken cancellationToken = default)
    {
        // Cancel the order
        return message with { IsCancelled = true };
    }
}

internal sealed class SendEmail() : Executor<Order, string>("SendEmail")
{
    public override ValueTask<string> HandleAsync(
        Order message, IWorkflowContext context, CancellationToken cancellationToken = default)
    {
        return ValueTask.FromResult(
            $"Cancellation email sent for order {message.Id} to {message.Customer.Email}.");
    }
}

internal sealed record Order(string Id, DateTime OrderDate, bool IsCancelled, Customer Customer);
internal sealed record Customer(string Name, string Email);

WorkflowBuilder

The WorkflowBuilder wires executors into a directed graph. You define edges between executors to control the flow of data and the builder produces an immutable Workflow object.

OrderLookup orderLookup = new();
OrderCancel orderCancel = new();
SendEmail sendEmail = new();

// Build the CancelOrder workflow: OrderLookup -> OrderCancel -> SendEmail
Workflow cancelOrder = new WorkflowBuilder(orderLookup)
    .WithName("CancelOrder")
    .WithDescription("Cancel an order and notify the customer")
    .AddEdge(orderLookup, orderCancel)
    .AddEdge(orderCancel, sendEmail)
    .Build();

This runs entirely in memory using InProcessExecution.RunAsync:

string result = await InProcessExecution.RunAsync(cancelOrder, "12345");

But if the process crashes, the workflow state is lost. The hosting package solves that.

Hosting Workflows on Azure Functions

The Microsoft.Agents.AI.Hosting.AzureFunctions package bridges MAF workflows with the Azure Functions runtime. You define your workflow the same way, then register it with a single call to ConfigureDurableWorkflows. The framework auto-generates all the necessary durable function triggers, orchestrator functions, and HTTP endpoints.

Why Azure Functions?

Hosting workflows on Azure Functions brings several benefits beyond just durability:

Serverless scaling - Azure Functions automatically scales out based on workload. Workflow executions scale independently without managing infrastructure.
Pay-per-execution pricing - You only pay for the compute time your executors actually use, making it cost-effective for bursty or low-traffic workflows.
Built-in HTTP endpoints - Each registered workflow gets an HTTP trigger automatically. No need to write controllers or routing logic.
Durable Task Scheduler integration - Workflow state is persisted and managed by the Durable Task Scheduler, providing reliability, observability, and cross-process coordination out of the box.
Zero boilerplate - The hosting package generates orchestrator functions, activity functions, and entity functions from the workflow definition. The only code to write is the executors and the workflow graph.
MCP tool support - Workflows can be exposed as MCP tools with a single flag, making them discoverable by AI agents and other MCP-compatible clients.

Install the package:

dotnet add package Microsoft.Agents.AI.Hosting.AzureFunctions

📂 View the full sample on GitHub

Here’s a complete Program.cs for a Functions app that hosts the CancelOrder workflow:

using Microsoft.Agents.AI.Hosting.AzureFunctions;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Hosting;

// Define executors
OrderLookup orderLookup = new();
OrderCancel orderCancel = new();
SendEmail sendEmail = new();

// Build the CancelOrder workflow: OrderLookup -> OrderCancel -> SendEmail
Workflow cancelOrder = new WorkflowBuilder(orderLookup)
    .WithName("CancelOrder")
    .WithDescription("Cancel an order and notify the customer")
    .AddEdge(orderLookup, orderCancel)
    .AddEdge(orderCancel, sendEmail)
    .Build();

// Host it on Azure Functions
using IHost app = FunctionsApplication
    .CreateBuilder(args)
    .ConfigureFunctionsWebApplication()
    .ConfigureDurableWorkflows(workflows => workflows.AddWorkflow(cancelOrder))
    .Build();

app.Run();

The key addition here is .ConfigureDurableWorkflows() — an extension method provided by the Microsoft.Agents.AI.Hosting.AzureFunctions package. It’s the single call that bridges your MAF workflow definition to the Azure Functions runtime. Everything else in Program.cs is standard Azure Functions boilerplate.

Behind the scenes, the hosting layer automatically maps your workflow concepts to Durable Functions primitives:

Your workflow becomes an orchestrator function — the workflow graph is translated into a durable orchestration that coordinates the execution of each step
Each executor becomes an activity function — executors are wrapped as durable activity functions, giving them automatic retry, checkpointing, and fault tolerance
An HTTP trigger is generated to start the workflow: POST /api/workflows/CancelOrder/run
Integration with the Durable Task Scheduler provides durability and scale

Because these are standard Azure Functions under the hood, you automatically get all the platform benefits — auto-scaling, built-in monitoring via Application Insights, distributed tracing, and the full Azure Functions observability and diagnostics tooling — without writing any extra infrastructure code.

When you run func start, you can see these auto-generated functions in the terminal output. Notice the dafx- prefixed functions — these are the durable activity and orchestration triggers that the hosting package generated from your workflow definition:

The http-CancelOrder function is the HTTP endpoint you’ll call to start the workflow, while the dafx-* functions are the internal plumbing: dafx-CancelOrder is the orchestrator, and dafx-OrderLookup, dafx-OrderCancel, and dafx-SendEmail are the activity triggers — one for each executor in the workflow graph.

Invoking the Workflow

Once the Functions app is running, you can trigger the workflow with a simple HTTP request:

POST http://localhost:7071/api/workflows/CancelOrder/run
Content-Type: text/plain

12345

This starts the orchestration asynchronously and returns a 202 Accepted response with a run ID. The workflow then executes durably in the background, looking up order 12345, cancelling it, and sending a confirmation email.

Complex JSON inputs are also supported:

POST http://localhost:7071/api/workflows/BatchCancelOrders/run
Content-Type: application/json

{"orderIds": ["1001", "1002", "1003"], "reason": "Customer requested", "notifyCustomers": true}

You can register multiple workflows in a single Functions app. Executors can even be shared across workflows:

// OrderStatus reuses the same OrderLookup executor as CancelOrder
Workflow orderStatus = new WorkflowBuilder(orderLookup)
    .WithName("OrderStatus")
    .WithDescription("Look up an order and generate a status report")
    .AddEdge(orderLookup, statusReport)
    .Build();

.ConfigureDurableWorkflows(workflows =>
    workflows.AddWorkflows(cancelOrder, orderStatus, batchCancelOrders))

Fan-Out / Fan-In (Parallel Execution)

When you need multiple agents to process the same input concurrently, use the fan-out / fan-in pattern. AddFanOutEdge sends a message to multiple executors in parallel, and AddFanInBarrierEdge waits for all of them to complete before proceeding.

📂 View the full sample on GitHub

Here’s a workflow where a physics agent and a chemistry agent both answer the same question, and an aggregator combines their responses:

// Create AI agents as executors
AIAgent physicist = chatClient.AsAIAgent(
    "You are a physics expert. Be concise (2-3 sentences).", "Physicist");
AIAgent chemist = chatClient.AsAIAgent(
    "You are a chemistry expert. Be concise (2-3 sentences).", "Chemist");

ParseQuestionExecutor parseQuestion = new();
AggregatorExecutor aggregator = new();

// Build workflow: ParseQuestion -> [Physicist, Chemist] (parallel) -> Aggregator
Workflow workflow = new WorkflowBuilder(parseQuestion)
    .WithName("ExpertReview")
    .AddFanOutEdge(parseQuestion, [physicist, chemist])
    .AddFanInBarrierEdge([physicist, chemist], aggregator)
    .Build();

// Host on Azure Functions
using IHost app = FunctionsApplication
    .CreateBuilder(args)
    .ConfigureFunctionsWebApplication()
    .ConfigureDurableWorkflows(workflows => workflows.AddWorkflow(workflow))
    .Build();

app.Run();

Notice how AIAgent instances can be used directly in the workflow graph, just like any other executor. The AsAIAgent extension method creates an agent from a chat client and system prompt.

Human-in-the-Loop

One of the most powerful patterns is human-in-the-loop, which pauses a workflow to wait for external approval or input before continuing. This is modeled using RequestPort.

A RequestPort acts like an executor in the graph, but instead of processing data automatically, it pauses the workflow and waits for an external response. When hosted on Azure Functions, the framework auto-generates HTTP endpoints for checking pending requests and submitting responses.

📂 View the full sample on GitHub

Here’s an expense reimbursement workflow with three approval gates (one manager approval, then two parallel finance approvals):

// Define executors and RequestPorts for the HITL pause points
CreateApprovalRequest createRequest = new();
RequestPort<ApprovalRequest, ApprovalResponse> managerApproval =
    RequestPort.Create<ApprovalRequest, ApprovalResponse>("ManagerApproval");
PrepareFinanceReview prepareFinanceReview = new();
RequestPort<ApprovalRequest, ApprovalResponse> budgetApproval =
    RequestPort.Create<ApprovalRequest, ApprovalResponse>("BudgetApproval");
RequestPort<ApprovalRequest, ApprovalResponse> complianceApproval =
    RequestPort.Create<ApprovalRequest, ApprovalResponse>("ComplianceApproval");
ExpenseReimburse reimburse = new();

// Build the workflow with sequential and parallel approval gates
Workflow expenseApproval = new WorkflowBuilder(createRequest)
    .WithName("ExpenseReimbursement")
    .WithDescription("Expense reimbursement with manager and parallel finance approvals")
    .AddEdge(createRequest, managerApproval)
    .AddEdge(managerApproval, prepareFinanceReview)
    .AddFanOutEdge(prepareFinanceReview, [budgetApproval, complianceApproval])
    .AddFanInBarrierEdge([budgetApproval, complianceApproval], reimburse)
    .Build();

// Host on Azure Functions with status endpoint enabled
using IHost app = FunctionsApplication
    .CreateBuilder(args)
    .ConfigureFunctionsWebApplication()
    .ConfigureDurableWorkflows(workflows =>
        workflows.AddWorkflow(expenseApproval, exposeStatusEndpoint: true))
    .Build();

app.Run();

With exposeStatusEndpoint: true, the framework generates three HTTP endpoints for this workflow:

POST /api/workflows/ExpenseReimbursement/run - Start the workflow
GET /api/workflows/ExpenseReimbursement/status/{runId} - Check status and see pending approvals
POST /api/workflows/ExpenseReimbursement/respond/{runId} - Submit an approval response to resume

External systems (or humans via a UI) can poll the status endpoint to see which approvals are pending, then POST a response to unblock the workflow. The respond endpoint expects a JSON body with the eventName (matching the RequestPort name) and the response data:

POST http://localhost:7071/api/workflows/ExpenseReimbursement/respond/{runId}
Content-Type: application/json

{"eventName": "ManagerApproval", "response": {"approved": true, "comments": "Looks good"}}

Exposing Workflows as MCP Tools

With the exposeMcpToolTrigger: true option, your workflows become callable as MCP (Model Context Protocol) tools. Other AI agents or MCP-compatible clients can discover and invoke your workflows as tools.

📂 View the full sample on GitHub

// Define workflow
Workflow orderLookupWorkflow = new WorkflowBuilder(lookupOrder)
    .WithName("OrderLookup")
    .WithDescription("Look up an order by ID and return enriched order details")
    .AddEdge(lookupOrder, enrichOrder)
    .Build();

// Expose as MCP tool
using IHost app = FunctionsApplication
    .CreateBuilder(args)
    .ConfigureFunctionsWebApplication()
    .ConfigureDurableWorkflows(workflows =>
    {
        workflows.AddWorkflow(orderLookupWorkflow,
            exposeStatusEndpoint: false, exposeMcpToolTrigger: true);
    })
    .Build();

app.Run();

The Functions host generates a remote MCP endpoint at /runtime/webhooks/mcp with a tool for each registered workflow. The workflow’s .WithName() and .WithDescription() are used as the MCP tool name and description.

Agents and Workflows Together

When you need to register both standalone AI agents and workflows in a single Functions app, use ConfigureDurableOptions — the more general sibling of ConfigureDurableWorkflows that gives you access to both options.Agents and options.Workflows:

📂 View the full sample on GitHub

// Define a standalone AI agent
AIAgent assistant = chatClient.AsAIAgent(
    "You are a helpful assistant. Answer questions clearly and concisely.",
    "Assistant",
    description: "A general-purpose helpful assistant.");

// Define a workflow
Workflow translateWorkflow = new WorkflowBuilder(translateText)
    .WithName("Translate")
    .WithDescription("Translate text to uppercase and format the result")
    .AddEdge(translateText, formatOutput)
    .Build();

// Register both with Azure Functions
using IHost app = FunctionsApplication
    .CreateBuilder(args)
    .ConfigureFunctionsWebApplication()
    .ConfigureDurableOptions(options =>
    {
        options.Agents.AddAIAgent(assistant,
            enableHttpTrigger: true, enableMcpToolTrigger: true);
        options.Workflows.AddWorkflow(translateWorkflow,
            exposeStatusEndpoint: false, exposeMcpToolTrigger: true);
    })
    .Build();

app.Run();

More Workflow Patterns

The workflow programming model supports several additional patterns that work with both in-process and durable execution:

Conditional Routing

Use AddSwitch to route messages to different executors based on the output of a previous step:

builder.AddSwitch(spamDetectionExecutor, switchBuilder =>
    switchBuilder
        .AddCase(
            result => result is DetectionResult r && r.spamDecision == SpamDecision.NotSpam,
            emailAssistantExecutor)
        .AddCase(
            result => result is DetectionResult r && r.spamDecision == SpamDecision.Spam,
            handleSpamExecutor)
        .WithDefault(handleUncertainExecutor));

Shared State

Executors can share data through scoped key-value state, useful when parallel executors need access to the same source data:

// Write to shared state in one executor
await context.QueueStateUpdateAsync(
    fileID, fileContent, scopeName: "FileContentState", cancellationToken);

// Read from shared state in another executor
var fileContent = await context.ReadStateAsync<string>(
    message, scopeName: "FileContentState", cancellationToken);

Sub-Workflows

Embed a workflow as an executor inside another workflow for modular, hierarchical architectures:

// Build a sub-workflow
var subWorkflow = new WorkflowBuilder(uppercase)
    .AddEdge(uppercase, reverse)
    .AddEdge(reverse, append)
    .WithOutputFrom(append)
    .Build();

// Use it as an executor in a parent workflow
ExecutorBinding subWorkflowExecutor = subWorkflow.BindAsExecutor("TextProcessing");

var mainWorkflow = new WorkflowBuilder(prefix)
    .AddEdge(prefix, subWorkflowExecutor)
    .AddEdge(subWorkflowExecutor, postProcess)
    .WithOutputFrom(postProcess)
    .Build();

When running on the durable runtime, sub-workflows execute as sub-orchestrations with proper result propagation.

Wrapping Up

Durable workflows in the Microsoft Agent Framework bring together the flexibility of AI agents and the reliability of durable orchestrations. With a few lines of code, you can build complex multi-step workflows and host them on Azure Functions with auto-generated HTTP endpoints, human-in-the-loop support, and MCP tool integration.

Here are some useful links to get started:

Give it a try and share your feedback or questions on the GitHub repo. Issues and contributions are welcome!

Cheers

Extending input binding pipeline in dotnet isolated Azure functions

Sat, 11 Feb 2023 08:00:00 +0000

The dotnet isolated model of azure functions has a binding pipeline which is responsible for populating your function inputs. While the built-in mechanism satisfies the majority of the binding use cases, there may be instances where you want to customize this pipeline.

Let’s get familiarized with a few terminologies before we move forward

Input conversion

The process of using the raw input data to populate all the function inputs appropriately.

Input converter

A small component responsible for converting the raw input to a specific type of function input type. The dotnet isolated package ships with a default set of converters and the Input conversion pipeline uses these converters to successfully bind all the function parameters.

Extending the input conversion pipeline

If the built-in converters are not handling your use cases, you may write your own input converter and register that with your function app. Let’s take a look at an example.

Imagine you have POCO like below to represent customer information.

public class Customer
{
    public string Name { get; set; }

    public string Gender { get; set; }

    public string Culture { get; set; }
}

and you want to use that type as a parameter of your function and you want to populate this from using some minimal information from your http request. For example, assume your http request includes the unique id of the customer in the route (ex: “/api/customers/123”) and you want to use that id value to pull the customer details from another source (ex: a database /XML file/ a REST API etc..)

[Function("Update")]
public HttpResponseData Update(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get",Route ="customers/{id}")] HttpRequestData req,
    Customer customer)
{
    _logger.LogInformation($"Processing request for {customer.Id}");

    //do something with the customer instance.

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.WriteString($"Processed {customer.Id} {customer.Name}");

    return response;
}

To make this happen, we will extend the input conversion pipeline with a custom converter.

Writing a custom input converter

Create a class and have it implement the IInputConverter interface. The InputConverter interface has a ConvertAsync method which we are going to implement with our custom logic.

public class CustomerConverter : IInputConverter
{
    public ValueTask<ConversionResult> ConvertAsync(ConverterContext context)
    {
        // we are going to replace this with actual implementation shortly.
        throw new NotImplementedException();
    }
}

The ConvertAsync method receives an instance of ConverterContext, from which we can get information about the raw input data and the target type (the parameter type) we are going to bind to. In this specific example, we need the Id value from the request URL/route. We could access that from the BindingContext on the FunctionContext.

public async ValueTask<ConversionResult> ConvertAsync(ConverterContext context)
{
    if (context.FunctionContext.BindingContext.BindingData.TryGetValue("id", out var idObj))
    {
        var id = Convert.ToInt32(idObj);
        try
        {
            var customer = await GetCustomerFromRestAPIAsync(id);
            if (customer is not null)
            {
                return ConversionResult.Success(customer);
            }
        }
        catch(Exception ex)
        {
            return ConversionResult.Failed(ex);
        }
    }

    return ConversionResult.Unhandled();
}

Here we are reading the Id route param value and using that to populate a Customer instance. The GetCustomerFromRESTAPIAsync method is simply calling a REST API to get the customer details.

private async Task<Customer?> GetCustomerFromRestAPIAsync(int id)
{
    var url = $"https://anapioficeandfire.com/api/characters/{id}";

    return await httpClient.GetFromJsonAsync<Customer?>(url);
}

httpClient is a static instance of HttpClient.

The above method is kept as minimal and simple. Modify as needed to make it more robust as needed.

You can see that we used 3 helper methods in our ConvertAsync code. Let’s take a look at what they do.

ConversionResult.Success

If the conversion is successful we return the result of ConversionResult.Success helper method, which returns an instance of ConversionResult with the Status property value set to Succeeded and Value property value set to the populated customer object.

ConversionResult.Failed

If there is was exception during the conversion, we use the ConversionResult.Failed helper which returns a ConversionResult instance with the Error property populated. The Status property value will be set to Failed in this case.

ConversionResult.Unhandled

Finally the ConversionResult.Unhandled method can be used when you want to tell the calling pipeline that this converter is not able to convert this specific input. Remember this converter will be called while trying to populate every function input (although there is a way to optimize this which you will see below). For example, the date time converter returns Unhandled when the target type is not a DateTime type or the source is not string.

https://github.com/Azure/azure-functions-dotnet-worker/blob/7d659ced053af41d58274ea4a36d2b5db2138750/src/DotNetWorker.Core/Converters/DateTimeConverter.cs#L16-L19

Register the custom converter in the pipeline.

The custom converter can be hooked up to the function app in any of the following 3 approaches.

1) App bootstrapping time

Add the new converter to WorkerOptions.InputConverters while bootstrapping the function app.

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(workerOptions =>
    {
        workerOptions.InputConverters.Register<CustomerConverter>();
    })
    .Build();

await host.RunAsync();

The above approach will add the custom converter as the last entry in the InputConverters collection. The binding pipeline calls each converter sequentially in the order they are registered. So in this case the CustomerConverter will be called only after all the built-in converters are called and all of them returned an Unhandled result.

If you want the custom converter to be used earlier, you can use the RegisterAt method.

// Adds MyCustomConverter to the set of available (built-in) converters, but at index 3. 
workerOptions.InputConverters.RegisterAt<CustomerConverter>(3);

2) Type level

Decorate the type used as the parameter of the function with InputConverter attribute where you will define the custom converter type to be used.

[InputConverter(typeof(BookConverter))]
public class Book
{
    public string Name { set; get; }

    public string Isbn { set; get; }
}

and

[Function("GetBook")]
public HttpResponseData Update(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get",Route ="books/{id}")] HttpRequestData req,
    Book book)
{
    _logger.LogInformation($"Processing request for {book.Name}");

    //do something with the Book instance.

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.WriteString($"Processed {book.Name}");

    return response;
}

The above example assumes that you have written a BookConverter similar to the CustomerConverter above which populates a Book instance.

3) Function parameter level

Decorate the function parameter using the InputConverter attribute

[Function("GetBook")]
public HttpResponseData Update(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "books/{id}")] HttpRequestData req,
    [InputConverter(typeof(BookConverter))] Book book)
{
    _logger.LogInformation($"Processing request for {book.Name}");

    //do something with the Book instance.

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.WriteString($"Processed {book.Name}");

    return response;
}

In this case, you do not need to decorate your book POCO with the InputConverter attribute.

public class Book
{
    public string Name { set; get; }

    public string Isbn { set; get; }
}

The last 2 approaches are more optimized than the first one since those will directly pick the explicitly specified converter for the parameter instead of going through all the registered converters.

Dependency Injection

Yes, dependency injection work with your custom input converters. You can inject dependencies to your converter class constructor.

public class BookConverter : IInputConverter
{
    private readonly ILogger<BookConverter> _logger;

    public BookConverter(ILogger<BookConverter> logger)
    {
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }
        
    public ValueTask<ConversionResult> ConvertAsync(ConverterContext context)
    {
        _logger.LogInformation($"BookConverter is the best!");
        throw new NotImplementedException();
    }
}

Take a look at this repo for a complete working sample.

Give it a try. If you are running into issues, please open a new issue in the dotnet worker repo.

Cheers

Azure functions V1 to V4 migration

Sun, 16 Oct 2022 05:00:00 +0000

Azure functions dotnet isolated model recently started supporting function apps targeting .NET Framework. This is great news for devs maintaining V1 version of function apps because they can now migrate their V1 apps to the latest function runtime version(V4).

Let’s take a look at the version history of function apps with the TFM & hosting models it supported.

Function runtime	TFM support
V1	.NET framework, In-proc.only
V2 (Deprecated)	.Net core 2.X.
V3	Out of process model is introduced. .NET 5. In-proc model with .Net core 3.X.
V4	In-proc model with .Net 6. Out of process model is .Net6, .Net7 and .NET framework.

Until now, function apps created with V1 version could not migrate to the newer versions of functions runtime while maintaining the target framework, but it is possible now with the isolated model support of .NET framework TFM.

The important thing to keep in mind is that, you will be migrating your in-proc app to isolated model.

In-proc to Isolated migration

We will use a very simple V1 function app with Http trigger for the migration example.

1) Update the project file

Open your project file (.csproj) and make the below edits.

Update the AzureFunctionsVersion value from v1 to v4.
Add OutputType entry with value Exe.
Update PackageReferences.

The in-proc model uses the Microsoft.NET.Sdk.Functions package. In the isolated model, we use a different set of packages.

The below 2 packages are needed for all isolated function apps.
- Microsoft.Azure.Functions.Worker
- Microsoft.Azure.Functions.Worker.Sdk
The below package is needed for Http functions. Since our example is migrating a function app with HttpTrigger, we need this package as well. In the in-proc model, the Microsoft.NET.Sdk.Functions implicitly brings the Microsoft.Azure.WebJobs.Extensions.Http package for http function support.
- Microsoft.Azure.Functions.Worker.Extensions.Http

So after these changes, your .csproj file will look like this:

The isolated model function app should not have a reference to Microsoft.NET.Sdk.Functions package. That package is only meant for in-proc function apps.

2) Update configuration files

Open your local.settings.json file and add a new entry under Values with key FUNCTIONS_WORKER_RUNTIME and value dotnet-isolated

You can remove AzureWebJobsDashboard entry if present in your config.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

3) Add a Program.cs with startup code

Create a new class called Program.cs and paste the below code to it.

internal class Program
{
    static void Main(string[] args)
    {
        FunctionsDebugger.Enable();

        var host = new HostBuilder()
            .ConfigureFunctionsWorkerDefaults()
            .Build();

        host.Run();
    }
}

This is the bootstrapping code for the isolated function application. It creates a generic host, configure the services needed for it to work as a function app, build the host and run it. This is where you will register additional dependencies to the DI container or configure logging etc, as needed.

4) Switch to the new types

The v1 in-proc version uses types from the Microsoft.Azure.WebJobs namespace. In the isolated model, we do not use these types, instead a new set of types were introduced in the isolated model. So replace the using statements with using Microsoft.Azure.Functions.Worker from which we will use a few types.

In in-proc model, functions are decorated with the FunctionName attribute. In the isolated model, we will use the Function attribute.
In the Isolated model, the HttpRequestData type wraps information about the http request, instead of HttpRequestMessage
In the Isolated model, the HttpResponseData type should be used as the return type for Http functions.
Use the extension methods of HttpRequestData and HttpResponseData to read/write http request/response.
For logging, V1 in-proc app uses TraceWriter from Microsoft.Azure.WebJobs.Host. In the V4 isolated model, you will use the ILogger type. This experience will be same as logging in .net/ASP.NET core apps. You can inject an ILogger instance via constructor injection. See example here
You can add a parameter of type FunctionContext in your functions to get contextual information about the function being executed. See example here.

Ideally, An isolated function should not have any reference to the Microsoft.Azure.WebJobs package. Packages with Microsoft.Azure.Functions.Worker prefix is what you need in your isolated function app.

You should be good to run your app now. If you are using Visual studio, press F5 to start debugging.

IDE support

For users who uses Visual Studio as their IDE, you need to use Visual studio 2022 Preview 17.4.0 Preview 3 or later for F5 debugging to work.

If you are still running into issues when debugging a .net framework function app, even after installing preview 3 or later, It is possible that VS failed to automatically update the azure functions tools to latest version. In this case, you shall manually update the azure functions tools using the Options dialog.

Tools -> Options -> Projects & Solutions -> Azure functions and click on the “Check for updates” button.

Install the updates as needed.

Restart Visual Studio and try to create a new Azure functions project and you should see “.NET Framework Isolated” in the functions worker dropdown.

Here are some useful links to make your migration experience a breeze:

Guide for running C# Azure Functions in an isolated process
Refer this sample solution which has V1 in-proc project and V4 isolated version of the same.
Isolated function app samples in the dotnet worker repo.
Bindings & Triggers in isolated model
Follow Azure functions on twitter

If you are running into issues with the migration process, please open a new issue in the dotnet worker repo.

Cheers

Useful APIs for writing azure functions middleware

Sun, 15 May 2022 05:00:00 +0000

One of the benefits of using isolated (out-of-process) model is the ability to plug in custom middlewares in the invocation pipeline. In this post, I will go through some of the handy APIs you can use to make your middleware authoring experience easier. All these APIs are extension methods on FunctionContext instance which is available in the Invoke method of the middleware.

HTTP Trigger specific APIs

Let us take a look at 2 APIs specific to Http triggers.

GetHttpRequestDataAsync

The GetHttpRequestDataAsync extension method can be used to obtain an instance of HttpRequestData when called during an http trigger invocation. In the isolated function model, the HttpRequestData instance represents the http trigger specific information, which is useful when you want to read/update http trigger specific data, such as request/response headers and cookies. The GetHttpRequestDataAsync returns a ValueTask<HttpRequestData?> instance, which you could await to get the HttpRequestData instance.

HttpRequestData? httpReqData = await functionContext.GetHttpRequestDataAsync();

This method will return null if called during a non http trigger invocation.

GetHttpResponseData

The GetHttpResponseData extension method can be used to get an instance of HttpResponseData when called during an http trigger invocation. This method will return null if called during a non http trigger invocation or when the function return type is not HttpResponseData.

The following is an example of a middleware implementation which reads the HttpRequestData instance and updates the HttpResponseData instance during function execution. This middleware checks for the presence of a specific request header(x-correlationId), and when present uses the header value to stamp a response header. Otherwise, it generates a new GUID value and uses that for stamping the response header.

We can use the UseWhen extension method to register this middleware, where we can write a predicate which returns true, only when the invocation is for an http trigger. This way, our middleware will be participating in the invocation pipeline only for http trigger invocations.

APIs applicable to all trigger types.

GetInvocationResult

The GetInvocationResult method gets an instance of InvocationResult, which represents the result of the current function execution. The InvocationResult type has a Value property to get or set the value as needed.

This method is useful when you want to alter the return value of the function inside a middleware. For example, you can write a global exception handler like below where you will update the return value when an exception happens during the invocation.

There is another overload of GetInvocationResult where you can specify the type you are expecting as the return type of the invocation.

 var invocationResult = context.GetInvocationResult<HttpResponseData>();

GetOutputBindings

The GetOutputBindings method gets the output binding entries collection for the current function execution. Each entry in the collection is of type OutputBindingData<T>. You can use the Value property to get or set the value as needed.

IEnumerable<OutputBindingData<object>>? allOutputBindings = context.GetOutputBindings<object>();

This method is useful if you want to update the invocation result of a function which has multiple output bindings.

For example, if you have a function like below where the return type of the function is a type which has properties decorated with output binding attributes.

You can use the GetOutputBindings method to get the output binding entries and update them as needed. Below is an example where we are updating the value of the queue output binding entry.

BindInputAsync

The BindInputAsync method binds an input binding item for the requested BindingMetadata instance. For example, you can use this method when you have a function with a BlobInput input binding that needs to be accessed or updated by your middleware. Imagine you have a function like below,

You can access all the input bindings for your function from the function context(via the FunctionDefinition property) and update the entry values. In the below snippet, I am updating only the blob input entry’s value.

Please give these APIs a try. These are available from version 1.8.0-preview1 onwards.

Cheers

Go-load, A simple load testing tool written in go

Sun, 23 May 2021 05:00:00 +0000

Go-load, A simple load testing tool written in go

As I was learning golang, I wrote a simple load testing tool in it and have been using it for generating consistent load test traffic while I try to collect profiling data on my .net apps.

Usage

Prerequisites

Make sure you have installed go runtime in your machine

Install go-load binary

Open a terminal/command prompt and run the below go get command which will install the go-load binary. This will download the source code to your machine and build the go-load.exe.

go get github.com/kshyju/go-load

Command line options

-c : Specifies the number of concurrent connections(goroutines) to use. You can consider this as the RPS you want for the test. Ex: -c 50 will send 50 requests/second.
-d : Specifies the duration of the load test in seconds. Ex: -d 30 will run the tests for 30 seconds.
-h : Specifies the request headers to send in a comma separated form. Each header item can use the key:value format. Ex: my-apikey:foo,cookie:uid
-body : Specifies the path to a local file name which has the request payload data present. go-load will read the content of this file and use that as the request body. When this option is passed, Http POST method will be used to send the request.
-u : Specifies the request URL explicitly.

Examples

Send 10 requests/sec to bing.com for 30 seconds

go-load -c 10 -d 30 https://www.bing.com

If you have special characters like & in your URL, you need to pass the value in quotes.

go-load -c 10 -d 30 "https://www.bing.com?how=are&you=today"

Sending request headers

Request headers can be passed as a comma separated string with the -h flag. The string should have header key and value in the key:value format. Ex: User-Agent:Go-http-client/1.1

go-load -c=10 -d=30 -h my-apikey:foo,cookie:uid:bar https://www.bing.com

The above example is sending 2 request headers, “my-apikey” and “cookie”.

Sending HTTP POST request with payload from a local file

go-load -c=10 -d=30 -body="C:\\temp\\my-payload.json" "http://your.app/which/accepts/http-post?foo=bar"

At the end of the run, go-load will generate a run summary which includes latency(different percentiles) and aggregated status code count.

Source code

Cheers

A fast alternative to Linq's Intersect.Any() expression result

Sat, 15 May 2021 05:00:00 +0000

A fast alternative to Linq’s Intersect.Any() expression result

While looking at the profiling data of one of our production systems, I stumbled across this interesting block in the CPU flame graph.

Let’s call the obscured method GetData. Over 80 % of the time in GetData is spent in the LINQ expression where the Any extension method is called on the result of Intersect extension method. This GetData method was obviously in hot path of the application, getting executed multiple times per incoming request.

The goal of using this LINQ expression in our GetData method was to find whether there was a common element present between two string collections. Something like below.

The profiler also tells us that this method took ~5 % of total CPU of our service process.

Looking at the source code of Intersect method, we can see it does two things.

Creates a Hash set and add items from first collection to it.
Tries to remove each items of second collection from this hash set as we iterate through the result of this method. The Remove method returns True when it successfully removes an item (a match has been found) and return those removed items(the common items).

The Intersect method returns an Enumerable collection(deferred execution). So If the Any method returns True, it won’t execute the code for remaining elements in second collection.

In my case, All I care about is finding out whether we have a common element present between these 2 collections. We could do this just with a nested for loop without allocating the HashSet. We could also eliminate the hash generation during the Remove method call. I wrote an extension method like below which uses 2 simple for loops.

This may look like a brute force solution. Would it do better compared to the LINQ expression? Only way to tell that is by measuring both implementations. So I wrote benchmarking code for these 2 implementations with 2 types of source collections, Arrays and Lists. Our extension method uses a for loop on an array. So If the collection passed in is not an array, it will call the AsArray extension method to convert that collection to an array.

The benchmark results

The benchmark results clearly shows:

When both the source collections are Arrays, the custom implementation is 7 times faster than the LINQ expression. Also it allocates 0 bytes (no hash set allocation in managed heap. The for loop runs on the stack)
When both the source collections are Lists, the custom implementation is 4.5 times faster than the LINQ expression. There is allocation where our AsArray method has to convert the collection to an Array. But still a lot smaller than what the LINQ expression allocated.

And finally, after deploying the fix to prod, I went back and checked the prod profiler data again.

The GetData method now consumes 1.6 % CPU where it used to consume around 5 %.

Key takeaways are,

LINQ expression is concise, but may not be optimal if that is being used in a hot path. Many times, you can write a faster implementation which handles your specific use case
Measure, Fix, Measure again, Repeat.

Cheers

Deserialize JSON arrays from object type with $type and $values in System.Text.Json

Sat, 24 Apr 2021 05:00:00 +0000

Deserializing JSON arrays from object type with $type and $values in System.Text.Json

The JSON spec says an array type property should be represented in a structure surrounded by square brackets.

An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas.

array = begin-array [ value *( value-separator value ) ] end-array

Imagine working with a class like this for serialization/deserialization.

public sealed class Person
{
    public string FullName { get; set; }        
    public List<Vehicle> Vehicles { get; set; }
}

public sealed class Vehicle 
{
    public int Year { get; set; }
    public string Model { get; set; }
}

A valid JSON string adhering to RFC spec, which can be successfully deserialized to an instance of Person would be like this

{
    "fullName": "Kramer",
    "vehicles": [
        {
            "year": 2012,
            "model": "Accord"
        },
        {
            "year": 2000,
            "model": "Altima"
        }
    ]
}

Deserialization for the above JSON string works fine with both Newtonsoft JSON.NET and System.Text.JSON

var personSystemTextJson = System.Text.Json.JsonSerializer.Deserialize<Person>(json, _options);
var personNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<CardInfo>(json);

The other array format

I recently learned that arrays can be represented in another way in the JSON string. This is clearly not standard syntax as per the JSON spec. Take a look at this JSON string.

{
    "fullName": "Kramer",
    "vehicles": {
    "$type": "System.Collections.Generic.List`1[[Vehicle, My.Project]], mscorlib",
    "$values": [
            {
                "year": 2012,
                "model": "Accord"
            },
            {
                "year": 2000,
                "model": "Altima"
            }
        ]
    }
}

Here vehicles is using an object structure. The object has a $type and $values sub properties. The value part of $values token actually holds the real array. Newtonsoft.JSON.NET will successfully deserialize this JSON string to a Person instance while System.Text.Json Will throw.

System.Text.Json.JsonException: The JSON value could not be converted to System.Collections.Generic.List`1[TestProject1.Vehicle]. Path: $.Vehicles | LineNumber: 2 | BytePositionInLine: 45. at System.Text.Json.ThrowHelper.ThrowJsonException_DeserializeUnableToConvertValue(Type propertyType) at System.Text.Json.JsonSerializer.HandleStartObject(JsonSerializerOptions options, ReadStack& state) at System.Text.Json.JsonSerializer.ReadCore(JsonSerializerOptions options, Utf8JsonReader& reader, ReadStack& readStack) at System.Text.Json.JsonSerializer.ReadCore(Type returnType, JsonSerializerOptions options, Utf8JsonReader& reader) at System.Text.Json.JsonSerializer.Deserialize(String json, Type returnType, JsonSerializerOptions options) at System.Text.Json.JsonSerializer.DeserializeTValue

I was recently bit by this behavior while trying to migrate a system from JSON.NET to STJ. STJ is more strict and tries to adhere to the RFC spec, hence it consider this JSON string as non valid.

Ideally we should consider fixing the JSON to be following the spec. But in my case, this was not a straight forward option for the other team to change this right away. So I ended up writing a custom JsonConverter to do this.

A converter basically allows us to customize the behavior of serialization/deserialization. So in my case, I created a converter for handling the deserialization of the type List<Vehicle>

Spend a few minutes to read the official documentation

I ended up writing my converter like below. The trick is to loop through the tokens, when you find the StartArray type token, deserialize from that position onwards.

public sealed class VehiclesArrayConverter : JsonConverter<List<Vehicle>>
{
    public override List<Vehicle> Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        // Let's check we are dealing with a proper array format([]) adhering to the JSON spec.
        if (reader.TokenType == JsonTokenType.StartArray)
        {
            // Proper array, we can deserialize from this token onwards.
            return JsonSerializer.Deserialize<List<Vehicle>>(ref reader, options);
        }
        
        // If we reached here, it means we are dealing with the JSON array in non proper array form
        // ie: using an object structure with "$type" and "$values" format like below 
        // We will go through each token and when we get the array type inside (for $values),
        // We will deserialize that token. We exit when we reaches the next end object.
        
        List<Vehicle> list = null;
        while (reader.Read())
        {
            if (reader.TokenType == JsonTokenType.StartArray)
            {
                list = JsonSerializer.Deserialize<List<Vehicle>>(ref reader, options);
            }
            if (reader.TokenType == JsonTokenType.EndObject)
            {
                // finished processing the array and reached the outer closing bracket token of wrapper object.
                break;
            }
        }

        return list;
    }

    public override void Write(Utf8JsonWriter writer, List<Vehicle> value, JsonSerializerOptions options)
    {
        // Nothing special to do in write operation. So use default serialize method.
        JsonSerializer.Serialize(writer, value, value.GetType(), options);
    }
} 

Finally, you have to hook this up with the type/property. I chose to do this on the property level using the JsonConverter attribute.

public sealed class Person
{
    public string FullName { get; set; }
    
    [JsonConverter(typeof(VehiclesArrayConverter))]
    public List<Vehicle> Vehicles { get; set; }
}

With this STJ can deserialize our non standard JSON string to Person instance properly.

We can make our implementation a bit more generic with C# generics. Here is a generic version of our converter.

public sealed class NonStrictArrayConverter<T> : JsonConverter<T>  where T : IEnumerable
{
    public override T Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        if (reader.TokenType == JsonTokenType.StartArray)
        {
            // Proper array, we can deserialize from this token onwards.
            return JsonSerializer.Deserialize<T>(ref reader, options);
        }
        
        var value = default(T);
        while (reader.Read())
        {
            if (reader.TokenType == JsonTokenType.StartArray)
            {
                value = JsonSerializer.Deserialize<T>(ref reader, options);
            }
            if (reader.TokenType == JsonTokenType.EndObject)
            {
                // finished processing the array and reached the outer closing bracket token of wrapper object.
                break;
            }
        }

        return value;
    }

    public override void Write(Utf8JsonWriter writer, T value, JsonSerializerOptions options)
    {
        JsonSerializer.Serialize(writer, value, value.GetType(), options);
    }
}

and we can hook it up to any collection properties.

public sealed class Person
{
    public string? FullName { get; set; }
    
    [JsonConverter(typeof(NonStrictArrayConverter<IReadOnlyList<Vehicle>>))]
    public IReadOnlyList<Vehicle>? Vehicles { get; set; }
    
    [JsonConverter(typeof(NonStrictArrayConverter<List<Color>>))]
    public List<Color>? Colors { get; set; }
    
    public string[]? Aliases { get; set; }
}

Couple of unit tests covering different cases: https://gist.github.com/kshyju/54d3dd1ee196a4d6c5fd61794d70027a

C# to Go - How to wait for an array of sub tasks to finish in Go

Sun, 28 Mar 2021 05:00:00 +0000

C# to Go - How to wait for an array of sub tasks to finish

In C#, Task.WhenAll allows us to wait for a collection of tasks(which may be executed concurrently) to finish. In go, we can use WaitGroup from sync package along with goroutines to achieve similar thing.

WhenAll

C# Console program code using Task.WhenAll to wait for the completion of a bunch of tasks running parallely.

namespace ConsoleApp
{
    using System;
    using System.Diagnostics;
    using System.Net.Http;
    using System.Threading.Tasks;

    class Program
    {
        static async Task Main(string[] args)
        {
            var start = Stopwatch.StartNew();

            var tasks = new Task[10];

            for (var i = 0; i < 10; i++)
            {
                tasks[i] = MakeRestCallAsync("https://bing.com");
            }
            await Task.WhenAll(tasks);

            start.Stop();
            var elapsed = start.Elapsed;

            Console.WriteLine($"Total Elapsed time {elapsed.TotalMilliseconds}ms");
        }

        static async Task MakeRestCallAsync(string url)
        {
            try
            {
                var start = Stopwatch.StartNew();

                using var httpClient = new HttpClient();
                using HttpResponseMessage resp = await httpClient.GetAsync(url);
                resp.EnsureSuccessStatusCode();

                start.Stop();
                var elapsed = start.Elapsed;
                Console.WriteLine($"{url} {(int)resp.StatusCode} {resp.StatusCode} Elapsed: {elapsed.TotalMilliseconds}ms");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"{ex}");
            }
        }
    }
}

Go program (almost) equivalent waiting for parallel sub tasks.

package main

import (
    "fmt"
    "log"
    "net/http"
    "sync"
    "time"
)

func main() {

    var wg sync.WaitGroup

    start := time.Now()
    for counter := 0; counter < 10; counter++ {
        wg.Add(1) 
        // "go" keyword prefix to run the method as goroutine, achieving concurrency
        go makeRestCallAsync("https://bing.com", &wg)
    }

    wg.Wait()  // wait for all sub tasks to finish

    end := time.Now()
    elapsed := end.Sub(start)

    fmt.Printf("Total Elapsed time %s", elapsed)
}

func makeRestCallAsync(url string, wg *sync.WaitGroup) {
    start := time.Now()
    var resp, httpCallError = http.Get(url)
    if httpCallError == nil {
        end := time.Now()
        elapsed := end.Sub(start)
        fmt.Printf("%s %s Elapsed: %s \n", url, resp.Status, elapsed)

        wg.Done() // mark this instance of the task as done.
    } else {
        log.Fatal(httpCallError)
    }
}

You can check this github repo for more samples.

Cheers

C# to Go - How to use StopWatch in Go

Sun, 21 Mar 2021 05:00:00 +0000

C# to Go - How to measure elapsed time

StopWatch type in C# provides an easy way to measure the time it took for a specific method execution. In go, we can use the time package to do similar thing.

Stopwatch

C# Console program code using StopWatch to record elapsed time.

namespace ConsoleApp
{
    using System;
    using System.Diagnostics;
    using System.Net.Http;
    using System.Threading.Tasks;

    class Program
    {
        static async Task Main(string[] args)
        {
            var start = Stopwatch.StartNew();

            for (var i = 0; i < 5; i++)
            {
                await MakeRestCallAsync("https://bing.com");
            }

            start.Stop();
            var elapsed = start.Elapsed;

            Console.WriteLine($"Total Elapsed time {elapsed.TotalMilliseconds}ms");
        }

        static async Task MakeRestCallAsync(string url)
        {
            try
            {
                var start = Stopwatch.StartNew();

                using var httpClient = new HttpClient();
                using HttpResponseMessage resp = await httpClient.GetAsync(url);
                resp.EnsureSuccessStatusCode();

                start.Stop();
                var elapsed = start.Elapsed;
                Console.WriteLine($"{url} {(int)resp.StatusCode} {resp.StatusCode} Elapsed time: {elapsed.TotalMilliseconds}ms");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"{ex}");
            }
        }
    }
}

Go program (almost) equivalent for recording elapsed time.

package main

import (
    "fmt"
    "log"
    "net/http"
    "time"
)

func main() {

    start := time.Now()
    for i := 0; i < 5; i++ {
        makeRestCallAsync("https://bing.com")
    }
    end := time.Now()
    elapsed := end.Sub(start)

    fmt.Printf("Total Elapsed time %s", elapsed)
}

func makeRestCallAsync(url string) {
    start := time.Now()
    var resp, httpCallError = http.Get(url)
    if httpCallError == nil {
        end := time.Now()
        elapsed := end.Sub(start)

        fmt.Printf("%s %s Elapsed time: %s \n", url, resp.Status, elapsed)
    } else {
        log.Fatal(httpCallError)
    }
}

You can check this github repo for more samples.

Cheers

C# to Go - How to make HTTP call in Go

Wed, 03 Mar 2021 05:00:00 +0000

C# to Go - How to make HTTP call in Go

I have been dabbling with Go programming language lately(really late to the party😅) and surely liking this language. Me, being a C# developer, thought it might be a good idea to rewrite some of the C# snippets as part of learning Go. As I was doing this exercise, I decided to scribble it down here as a quick reference to help anyone taking the same route (C# developer learning Go) or for myself in the future.

Step 1, Install go for your OS.

I am going to skip the Hello world sample here for obvious reasons and will be doing the Go equivalent of some the the C# snippets we will use in real world application development.

Http calls

C# Console program code for making Http call

class Program
{
    static async Task Main(string[] args)
    {
        Console.WriteLine("Http REST call demo");
        await MakeRestCallAsync("https://bing.com");
    }

    static async Task MakeRestCallAsync(string url)
    {
        try
        {
            using var httpClient = new HttpClient();
            using HttpResponseMessage response = await httpClient.GetAsync(url);
            response.EnsureSuccessStatusCode();
            Console.WriteLine($"{url} {(int)response.StatusCode} {response.StatusCode}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"{ex}");
        }
    }
}

Go program (almost) equivalent for making Http call

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    fmt.Println("Http REST call demo")
    makeRestCallAsync("https://bing.com")
}

func makeRestCallAsync(url string) {
    var resp, httpCallError = http.Get(url)
    if httpCallError == nil {
        fmt.Printf("%s %s", url, resp.Status)
    } else {
        log.Fatal(httpCallError)
    }
}

You can check this github repo for more samples.

Cheers