DEV Community: Omar Zouaid

Background Jobs and .NET Hosted Services

Omar Zouaid — Sat, 16 Oct 2021 20:50:45 +0000

Introduction :

Background jobs are an alternative to synchronous processing, it's an approach to lighten the main thread and offload tasks to a secondary thread.
To explain the concept let's imagine a web application dedicated to video processing which's obviously a heavy task, so the main application get the request from a third party application or the browser, then it delegates the task to a background job, but the main thread can't wait for the response cause it will take a considerable amount of time to finish the task from the worker job, so to free the main application thread the communication is established asynchronously by creating a message queue bridge between the application and background job, so the main application place the task in queue and then move on to get more processing request, and the background job can treat the requests at it's own speed.
The main criteria to decide whether a task can be executed in background or not is by asking yourself if the task need the interaction with user while in execution or the user is obliged to wait for the job result, if the answer is yes so the backgound job implementation can be inapropriate in this case.

Background jobs triggers types :

There's two type of background job triggers :
- Event driven trigger : the background job is launched in parallel with the main application when a start event is raised.
- Schedule driven trigger : in this approach the task is invoked periodically based on a timer.

Dotnet Core Hosted Services :

In the .Net core platform we can build background jobs by implementing IHostedService interface.

In the code above The StartAsync method is triggered when our service kicks off, it's a setup method where we configure and launch the background job to do the work.
On the other side StopAsync is called when we stop our background service so we can do whatever we need to dispose used resources.

The .Net hosted services are tied to the hosted service, that means
they are deployed with the main application within the same host
infrastructure.

Dotnet hosted service example :

We will create a simple hosted service which will simply print Hello World every 10 seconds, and inject it as hosted service to ASP .Net Api application.

1. Implemente IHostedService

In the code above we decalred an instance of a Timer object which will be configured to execute a callback method periodically.

The Timer is an object that raises an event after a number of milliseconds elapsed. You can configure the Timer object to raise the event just once or repeatedly.

In the StartAsync method we configured the timer to execute PrintHelloWord() periodically after each 10 seconds, in the other side StopAsync method is used to stop the timer callbacks when the job is turned off.

2. Configure API by adding our hosted service

We need to add our hosted service to ConfigureServices method in startup.cs :

And we are done if we start our api now MyHostedService will kicks off, check the Debug output to see the result 😉.

Hosted services limitation :

The hosted services are tied to the main host web application, so when we scale horizontally our web application it involves the creation of new job instance. So we should be aware of that and avoid using hosted services in cases where jobs will compete with each others and lead to unwanted behaviours.

Why we can't use Out or Ref parameters with Asynchronous method in .Net Core ?

Omar Zouaid — Tue, 14 Sep 2021 22:35:09 +0000

Do you ever find yourself in a situation where you need to return multiple values from a method?

The standard approach is whether to create a class object which hold all parameters as properties and use it as a return type, but this approach can be cumbersome and you will find yourself creating meaningless objects. Better approach is using dotnet Out parameters.

But it's not always possible to use out parameter, because in my case I was dealing with asynchronous method, and what I was unware of is the fact that the dotnet compiler forbid the use of out parameter inside asynchronous methods :

And that pushed me to wonder why asynchronous method are designed on that way? and how can I figure out a workaround to this limitation?

Internal State machine (IAsyncStateMachine)

So to understand the problem we need to know how compiler deals with Asynchronous code.

So Every time we have an asynchronous method, the compiler actually turns the method into an internal state object.

Internal state class is designed in build time and instantiated in run time by the CLR, it implements the IAsyncStateMachine interface. This class is responsible for keeping the state of your method during the life cycle of the asynchronous operation, it encapsulates all the variables of your method as fields, splits your code into sections that are executed as the state machine transitions between states, so that the thread can leave the method and when it comes back the state is intact.

Common Language Runtime (CLR) is .NET run-time environment that runs the code and provides services that make the development process easier.

So let's create a class with asnychronous method and see how generated class will looks like. In the code below ExampleAsyncMethod is our async method :



    public class ExampleAsyncMethod
    {
        public async Task ExampleAsyncMethod( )
        {
            string variable = string.Empty;
            await CallApiAsync();
            Debug.WriteLine("First Await");
            variable = "new value";
            await CallApiAsync();
            Debug.WriteLine("Second Await");
            variable = "second new value";
        }
        public async Task CallApiAsync()
        {
            //Api call
        }
}

When we try to build this code, .Net compiler will generate an internal state class :



[CompilerGenerated]
private sealed class <ExampleAsyncMethod>d_0 : IAsyncStateMachine
{
    //fields
    public int <>1_state;
    public ExampleAsync.ExampleAsync<>4_this;
    public AsyncTaskMethodBuilder<>t_builder;
    public TaskAwaiter<>u_1;
    public int <variable>5_1;
    // other fields

Examining the generated class, we notice that our internal variable “variable” is now a class field.

We can also see other class fields used internally to maintain the state of the IAsyncStateMachine, one of them is MoveNext() which is a method with a big switch block. So basically MoveNext() we'll be called whenever there's state transitions (task completed) in our asynchronous code. The code below is a part of the generated MoveNext() method :



private void MoveNext()
{
    int num = this.<>1_state;
    try
    {
        TaskAwaiter awaiter;
        ExampleAsync.ExampleAsync.< ExampleAsyncMethod > d_0d_;
        switch (num)
        {
            case 0:
                break;
            case :
                goto Label_00D6;
            default:
                this.< myVariable > 5_1 = 0;
                awaiter = this.<>4_this_this.CallApiAsync().GetAwaiter();
                if(awaiter.get_IsCompleted())
                {
                    goto Label_007E;
                }
                this.<>1__state = num;
                this.<>u__1 = awaiter;
                d__ = this;
                return;
        }
        awiter.GetResult();
        Debug.WriteLine("First Await");
        this.<variable> 5_1 = 1;
        TaskAwaiter awaiter2 = this.<>4_this.CallApiAsync().GetAwaiter;
        if(awaiter2.get_IsCompleted())
        {
            goto Label_00F2;
        }
    }
    this.<> 1__state = num = 1;
    this.<> u__1 = awaiter2;
    d__ = this;
    return;
Label_00D6:
    awaiter2 = this.<> u_1;
    this.<>u_1 = new TaskAwaiter();
    this.<>1_state = num - 1;
Label_00F2:

    /// other code labels

}

Back to our question

So we have seen how the compiler turn async method to state class, now let's go back on topic, Why we can't declare Out or Ref parameters in asynchronous method? So according to Lucian Wischik a member of the C# language design team, this problem is because of some limitation of CLR. Unfortunately in internal state class we can't store the address of an out or ref parameter, basically CLR has no safe way to deal with the address of an object. As consequence the compiler forbid the use of Ref and out parameters in asynchronous method.

Workaround

So till now I have explained why the CLR forbid the use of ref and out parameter in async method. But what can we do to overpass this limitation? My solution to this problem was using Tuples. Since the version 7, C# brought to table the notion of Tuples, an easy way to store multiple items in a single variable. So with tuples we can return mutuple values from method with no need to use out parameter.

So instead of using code like this (which is forbidden by the compiler):



public async Task<int> GetDataTaskAsync(out int parameters)
{
    //...
    return someIntValueTask;
}

I switch to Tuples :



public async Task<Tuple<int, int>> GetDataTaskAsync()
{
    //...
    Tuple<int, int> result = await TaskReturnTuple();
    return result;
}

In my case I just returned two values, but with Tuples we can return as many values as we want with no constraint.

I hope this article helped you to understand why we can't declare out and ref parameters in asynchronous method, if you have any question or comment please feel free to express your thoughts 😉.

Blazor in nutshell

Omar Zouaid — Fri, 08 Jan 2021 12:21:12 +0000

What's BLAZOR?

Blazor is a new framework from Microsoft designed to create SPAs (single page applications) UI, Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS ( Oops can't see Js 🤔 ). Blazor is an open source project from microsoft and was initialy released 2 years ago (January 2018). By releasing Blazor WebAssambly version in May 2020, the community has become much larger and people are getting more intrested.
The name of Blazor is a combination of two words, first one is Browser and second one is Razor. Razor is a template markup syntax, used to create dynamic web pages based on the C# programming language, that enables the programmer to use an HTML construction workflow in ASP .NET MVC Framework. The implication behind the name is instead of having to execute code in the server( like we used to do it with Razor pages apps) inorder to render HTML, Blazor is capable of doing the same thing but in the browser (without relying in one single line of JS).

How does Blazor Work ?

To understand how Blazor works we need to diffrentiate between two version of Blazor, Blazor server version and Blazor WebAssembly.

1. Blazor Server :

Blazor Server uses a standard ASP .NET Core application to run, and Within this application we can add server-side functionality such as DataBase communication, Authentification service...
Blazor server rely on SignalR which's is basically a library for ASP .Net used to add real-time web functionality to their applications based in the famous WebSocket protocol.
- Blazor server app handles a copy of the DOM for every connected client, and each UI transaction trigger an event that will transported to the server using SignalR WebSocket than the server will update the DOM or apply BackEnd functionality.

Note : Latency still a major problem of Blazor Server. Client is tied to the server with a webSocket protocol which bring into question the scalability of Blazor server App (virtual DOM management for each client need importante CPU, Storage and Network resources)

2. Blazor Wasm :

Blazor Wasm or Blazor WebAssembly is another supported way to host your Blazor pages in client-side and relying on WebAssembly Host system, which is an open web standards supported in all modern web browsers.
WebAssembly is an open standard for running binary programs in the browser with near-native performance. WebAssembly can go where JavaScript has not showed great performance (3D animation, media editing, high games ending ...).

Note : WebAssembly is not a programming language however it's a compile-target code (similar to .Net IL or java byteCode), so the idea behind it is simple, you write your code in any language you are familiar with and than your code is giong to be transpiled to webAssembly code, and finally executed in the browser.

So what happens when we run Blazor wasm app ? Technically when Blazor Wasm app is going to be launched, it will build and shipped like a DLL files (packaging format for .Net apps) + css files + Index.html, and than sent to the browser with a compact run time environement (2Mo) called Mono interpreter which is a lightweight dotnet Run-Time. Mono interpreter is responsable to transform DLL package to webAssembly code, this processus is only executed in the first transaction between the application and the Browser, after the initial HTTP request the application will run completly in the browser.

Note : Microsoft is working to reduce the size of the Mono interpreter by implementing AOT compilation which will impact the performance of Blazor Wasm app.

Blazor wasm app can be deployed as static files, so it can run independantly in the browser in offline state.

Where can I learn it ?

So here I will share with you some free ressources (you can also find great courses in Udemy, Pluralsight ...) that I found useful for learning Blazor :
That's all, I hope this article helped you somehow to understand the principal concepts behind Blazor, thank you 😉