Most of us, know by now that the g in gRPC does not stand for Google, it literally stands for nothing. I mean why not give Google the accolades since the project was created and is maintained by them 😃

There are areas where it shines and then of course there are limitations, we will take a look at those at the end of this article. In this article we will take a look at how we can create a simple .NET Core gRPC server, expose a unary rpc method and consume it using BloomRPC client.

Create the gRPC server

Add nuget package

Search for Grpc.AspNetCore and add the latest stable version to your project.

Create your .proto file

We are defining a service called Echo, which would have an rpc method called EchoMessage. Additionally we will also define the data transfer objects EchoRequest and EchoResponse.

syntax = "proto3"; // protocol buffer version
option csharp_namespace = "GrpcTrial";
package echo;
service Echo { // the service
  rpc EchoMessage (EchoRequest) returns (EchoResponse); // the rpc method
}
message EchoRequest {
  string message = 1; // index at which the property is available
}
message EchoResponse {
  string message = 1;
}

Set the proto file to build the server stub classes

As soon as we build our project, few base classes will be autogenerated for us, classes gRPC understands, all we have to do now is override the methods for our logic.

public class EchoService : Echo.EchoBase // Inherit from the auto generated base class
{
    // override the method and add our own logic
    public override Task<EchoResponse> EchoMessage(EchoRequest request, ServerCallContext context)
    {
         return Task.FromResult(new EchoResponse {  Message = $"Did you just say, {request.Message}"});
    }
}

Add the gRPC service to service container

public void ConfigureServices(IServiceCollection services)
{
      services.AddGrpc(); 
}

Add the gRPC middleware

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
      app.UseRouting();
      app.UseEndpoints(endpoints =>
      {
             endpoints.MapGrpcService<EchoService>();
      });
}

Call the RPC method from a client

For this article we will use BloomRPC, an open source GUI client for gRPC services.

Simply add the proto file inside BloomRPC app, enter the base uri of server, modify the payload, and send a request

Pretty neat! 👌

Though very promising, this is not a replacement for REST APIs or SignalR. It shines at places and has its own issues.

Pros

• High performance since it works on top of HTTP/2, additionally it also serializes the data over network reducing data size again
• Works for low-bandwidth systems, since the size of data over network is reduced
• Programming language agnostic, once we have a proto file the same can be used by almost all languages, imagine a microservice architecture where each service is built using a different programming language
• Bidirectional streaming capabilities, client can stream data to the server, server can stream data to the client, or both can happen at the same time.

Cons

• HTTP/2 and greater only, which might be a headache for clients/services on older versions of HTTP.
• There is a learning curve, getting used to protocol buffer, bidirectional streaming etc may take sometime.
• Not enough tooling is available, 🛑 I just couldn't make use of https using BloomRPC, from a console app it works seamlessly.

I have used gRPC to stream log messages from one component to another. Few of our backend jobs take time(even days) and logs are continuously written to flat files inside a VM, a gRPC connection is established between the VM and a service, logs are then pushed as soon as they arrive, giving the user visibility of what's happening behind the scenes with the process. 🌟 But more about streaming in my next articles.

I hope this post gave you some insights on gRPC and will help you get started. Thank you for reading. Cheers!

Resources

• gRPC official documentation
• BloomRPC GitHub page

I did a last minute registration, couldn't find anyone to join me, with a bit of hesitation ran solo 😑

Most of the themes were focused towards company's product use cases. I ended up picking the General theme, because I was not interested in any of them.

There was an area which bugged me for quite sometime and it was around HTTP polling which we were doing in a lot of places in our cloud app. The first thought that came to my mind was to use SignalR to be able to switch to a more real-time data transfer from server to client. The only problem was SignalR exposes a bidirectional channel and for the issue in hand it seemed unnecessary. The problems I wanted to solve were around status updates, log streaming etc wherein after a client-server handshake is established the client would not be sending any data to the server.

While exploring for other real-time data transfer options and talking to few other colleagues I came across this little known HTTP feature called Server-Sent Events, and it was exactly what I was looking for 👌

• It created a unidirectional channel
• Lightweight with less bloat
• Easy to setup

From Wikipedia

Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via an HTTP connection, and describes how servers can initiate data transmission towards clients once an initial client connection has been established.

Overall design

I am going to talk about a redacted and miniature version of what I built, but overall the same concepts would apply. By no means these are production ready 😋

Building blocks

Step 1 - Expose an Azure function to push text as events

Inside your Azure function app, Navigate to Development Tools > Advanced Tools

That should open up kudu service that runs your function app

Navigate to Debug Console > CMD

Find wwwroot sub folder and add a SampleLog.txt there (put whatever content you would want to send as events)

With our log file in place, lets create a function to access it.

Head back to functions tab and create a function Select a HTTP trigger template, since we need an API

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using System;
using System.Text;
using System.IO;
public static async Task Run(HttpRequest req, ILogger log, ExecutionContext context)
{
    var sampleLogPath = System.IO.Path.Combine(context.FunctionDirectory, "..\\SampleLog.txt");
    var allText = await File.ReadAllTextAsync(sampleLogPath);
    req.HttpContext.Response.Headers.Add("Content-Type", "text/event-stream");
    foreach (var line in allText.Split("\n"))
    {
        await Task.Delay(2000);
        byte[] bytes = Encoding.ASCII.GetBytes($"data:{line}\n\n");
        await req.HttpContext.Response.Body.WriteAsync(bytes);
        await req.HttpContext.Response.Body.FlushAsync();
    }
}

The response should start with data: and end with \n\n, as browsers look at this to figure that these are chunked events.

Step 2 - Expose an Azure function to send status updates at random intervals

Create another function, select the HTTP trigger template again

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using System.Text;
public static async Task Run(HttpRequest req, ILogger log)
{
    string[] states =
    {
        "Lorem", "Ipsum", "is", "simply", "dummy", "text", "of ", "the", "printing", "and", "typesetting", "industry"
    };
    req.HttpContext.Response.Headers.Add("Content-Type", "text/event-stream");
    Random random = new Random();           
    for (short i = 0; i < states.Length; i++)
    {
        await Task.Delay(random.Next(5, 15) * 1000);
        byte[] bytes = Encoding.ASCII.GetBytes($"data:{states[i]}\n\n");
        await req.HttpContext.Response.Body.WriteAsync(bytes);
        await req.HttpContext.Response.Body.FlushAsync();
    }
}

Our backend APIs are ready and serving data now.

Step 3 - Create a simple static page that has logic to consume both the events

Do make sure to replace the eventsource endpoints, I may delete my function app after a while

<!DOCTYPE html>
<html lang="en">
<head>
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0-beta3/css/all.min.css" integrity="sha512-Fo3rlrZj/k7ujTnHg4CGR2D7kSs0v4LLanw2qksYuRlEzO+tcaEPQogQ0KaoGN26/zrn20ImR1DfuLWnOo7aBA==" crossorigin="anonymous" referrerpolicy="no-referrer" />
</head>
<body>  
<i class="fas fa-file-alt fa-2x" onclick="streamlog()"></i>
<i class="fas fa-tasks fa-2x" onclick="streamevent()"></i>
<div id="cards" class="card-columns">
</div>
<script>

function streamlog() {
    var cards = document.getElementById("cards");
    var cardHtml = '<div class="card" style="background-color: #343a40!important; width:500px; height:300px; overflow-y: scroll;"><div class="card-header" style="background: #343a40; color:white">Log</div><div class="card-body" style="background: #343a40; color: yellow"><p id="log"></p></div></div>'
    cards.insertAdjacentHTML("beforeend", cardHtml);
    var logSource = new EventSource('https://kd-playground-functionapp.azurewebsites.net/api/StreamLogs?code=MuFPYxFQhc1q7CaxM2X8e8PLoJGoJWpo/8QUWABctC1g7WCObi9cOQ==');
    logSource.onmessage = function(event) 
    {
        var element = document.getElementById('log');
        if (element)
        {
            element.textContent += "<br>" + event.data;
        }
    };
}
function streamevent() {
    var cards = document.getElementById("cards");
    var cardHtml = '<div class="card" style="width:200px; height:300px;border:1px; background-color:#311b92;"><div class="card-header" style="color:white">Event Status</div><div class="card-body"><p id="status"></p></div></div>'
    cards.insertAdjacentHTML("beforeend", cardHtml);
    var logSource = new EventSource('https://kd-playground-functionapp.azurewebsites.net/api/HttpTrigger1?code=5C8YjKcM2D3Oj10iAq8F3BLHwnzkjNHMS24mac4tkG8pwxnP1ZGjzA==');
    logSource.onmessage = function(event) 
    {
        var element = document.getElementById('status');
        if (element)
        {
            element.textContent += "<br>" + event.data;
        }
    };
}
</script>
</body>
</html>

Step 4 - Create a repository in GitHub and push the html file

This should be pretty straight forward.

Step 5 - Serve html pages via DigitalOcean

You can use your preferred platform too

You should be able to create a DigitalOcean account using GitHub. They do give a 100$ free credit but in any case I think 3 static pages are free 😎

• Create a new app, select source as GitHub
• Select your repository and branch
• Name your static site
• Select starter pack and launch
• Once the build completes we should have our page deployed at a public URL
• Dont forget to add a CORS entry in your Azure function app for this URL

Final outcome

• By default, if the connection between the client and server closes, the connection is restarted, until it is explicitly closed by the client.
• Multiple events can be transferred over the same channel.
• Different events can be transferred over the same channel.

Break down of 24hrs

• ~10% spent on wrapping my head around what I wanted to build, feasibility in my mind
• ~20% spent on creating and testing azure functions
• ~40% spent on front end code :( i hate css
• ~20% spent on bringing it all together and e2e testing
• ~10% on prep for demo
• Also I did some basic research even before hackathon day 🤓

Few takeaways

• Make sure to ensure feasibility, you don't want to bang your head and end up pivoting, no harm in doing some research.
• Keep accounts created beforehand with max max max access.
• Jump straight into demo, do not build fancy presentations, there is no point if you cant showcase what you were able to build.
• Keep some buffer for questions, more questions mean people actually are interested and find value, OR they just didn't get it, in any case you get to explain them again.

Resources

1. Mozilla documentation on Server sent events
2. Checkout DigitalOcean
3. Checkout Azure functions

You should check that out for an intro to cancellation tokens and how we can use them in APIs.

In this post we will take a step further and take a look at

• How to cancel multiple tasks using the same cancellation token
• Link multiple token sources
  1. Track multiple cancellation tokens simultaneously so that we can cancel a task if either token requests cancellation
  2. Parent token, child token scenarios

Cancel multiple tasks using the same cancellation token

This one is pretty straight forward, we pass on the same token to multiple tasks, if cancellation is requested, all tasks are cancelled.

[HttpPost("~/longoperation")]
public async Task LongRunningOperation(CancellationToken token)
{
    _logger.LogInformation("Calling long running operations");

    Task one = LongRunningOperationOneAsync(token);
    Task two = LongRunningOperationTwoAsync(token);
    await Task.WhenAll(one, two);

    _logger.LogInformation("Done with long running operations");
}

private async Task LongRunningOperationOneAsync(CancellationToken token)
{
    await Task.Delay(1000);
    if (token.IsCancellationRequested)
    {
        _logger.LogError("LongRunningOperationOneAsync was cancelled");
    }
}

private async Task LongRunningOperationTwoAsync(CancellationToken token)
{
    await Task.Delay(1000);
    if (token.IsCancellationRequested)
    {
        _logger.LogError("LongRunningOperationTwoAsync was cancelled");
    }
}

After I initiated the request using Postman, I immediately hit cancel and this is how the application behaves.

When a cancellation request was encountered, both tasks processed it.

Link multiple token sources

⚡ Track multiple cancellation tokens simultaneously

Leverage CreateLinkedTokenSource to combine multiple tokens and build a CancellationTokenSource. This tokensource would start monitoring cancellation in any of the encapsulating tokens.

In our case, we created a new CancellationTokenSource and set it up to auto cancel after 500ms, and then we also have the token that is injected via the API request. We make use of CreateLinkedTokenSource method to generate a new CancellationTokenSource from the 2 tokens, which is then used further in our long running operation.

[HttpPost("~/longoperation")]
public async Task LongRunningOperation(CancellationToken token)
{
    CancellationTokenSource otherTokenSource = new CancellationTokenSource();
    otherTokenSource.CancelAfter(500); 

    // create a new tokensource out of available 2 cancellation tokens
    CancellationTokenSource tokenSourceToUse = CancellationTokenSource.CreateLinkedTokenSource(token, otherTokenSource.Token);

    _logger.LogInformation("Calling long running operation");
    await LongRunningOperationOneAsync(tokenSourceToUse.Token);
    _logger.LogInformation("Done with long running operation");
}

private async Task LongRunningOperationOneAsync(CancellationToken token)
{
    await Task.Delay(1000);
    if (token.IsCancellationRequested)
    {
        _logger.LogError("LongRunningOperationOneAsync was cancelled");
    }
}

After I initiated the request using Postman, I waited for sometime and this is how the application behaves.

Since our token triggers cancellation after 500ms automatically, our long running operation gets cancelled.

⚡ Parent token, child token scenarios

There are times when you would want to cancel child tasks but continue your parent tasks. For cases like these, we again leverage an overload of the CreateLinkedTokenSource method.

[HttpPost("~/longoperation")]
public async Task LongRunningOperation(CancellationToken parentToken)
{
    // create a tokensource out of parentToken
    CancellationTokenSource childTokenSource = CancellationTokenSource.CreateLinkedTokenSource(parentToken);
    childTokenSource.CancelAfter(500);

    _logger.LogInformation("Calling long running operation");
    await LongRunningOperationOneAsync(childTokenSource.Token);
    if (!parentToken.IsCancellationRequested)
    {
        _logger.LogInformation("Parent cancellation was never requested, continue processing 100 other operations");
    }
    _logger.LogInformation("Done with long running operation");
}

private async Task LongRunningOperationOneAsync(CancellationToken token)
{
    await Task.Delay(1000);
    if (token.IsCancellationRequested)
    {
        _logger.LogError("Child cancellation was requested");
    }
}

After I initiated the request using Postman, I waited for sometime and this is how the application behaves.

Since our child token triggers cancellation after 500ms automatically, our child task gets cancelled, but our parent token still continues to be available.

💡 Note

If parent token is cancelled, all child tokens will be cancelled automatically.

The Task Parallel Library provides us with a wide range of easy to use extensions around cancellation tokens, we can setup cancellation behavior for various mix and matches.

I hope this post gave you some insights on how we can leverage CancellationTokens. Thank you for reading. Cheers!

On the Web, the end user always has the cancel/refresh button at their disposal, and they wont hesitate to use it. But what about the process that was initiated on the server side? How do we as backend devs take care of that, we don't want to keep on processing a cancelled operation and exhaust our resources, do we?

In this post we will take a look at cancellation tokens in .NET and how we can leverage them for situations just like these.

Cancellation tokens

Cancellation tokens or the cancellation model in general belong to the Task Parallel Library. The library provides us a Type called CancellationTokenSource which encapsulates a CancellationToken object within it. CancellationTokenSource also provides us with other extensions to manage a cancelled operation.

On a high level, to make use of the cancellation model we need to do the following

• Run our logic inside a Task, this would accept a cancellation token
• We keep on monitoring for cancellation requests by taking a look at the cancellation token and handle them gracefully
• From outside our logic, some other operation informs our task that a cancellation is requested

Now since we are dealing with APIs in this post, there is no need for us to manage CancellationTokenSource as it is inherently injected by the framework as part of each request. All we have to do is manage the cancellation token.

Lets take a look at some snippets where we will pass CancellationToken as a parameter to our API endpoint. There is no need to build or manage the CancellationTokenSource.

⚡Make use of framework methods which accept cancellation tokens

[HttpPost("~/longoperation")]
public async Task<ActionResult> AnnoyingLongRunningOperation(CancellationToken token)
{
     try
     {
            _logger.LogInformation("Calling long running operation");
            await Task.Delay(1000000000, token); // our annoying long running task
            _logger.LogInformation("Done with long running operation");
     }
     catch (OperationCanceledException ex)
     {
          // handle ex
          _logger.LogError("Long running operation was cancelled");
     }
     return new OkObjectResult("Done!");
}

After I initiated the request using Postman, I immediately hit cancel and this is how the application behaves. As you can see, Task.Delay() throws an OperationCanceledException as soon as it encounters a cancellation request (it has its own logic to dispose objects etc), and we can handle that exception gracefully in our logic.

Likewise, we can leverage alot of framework methods which already accept cancellation tokens.

⚡Write your own method which accepts a cancellation token

[HttpPost("~/longoperation")]
public async Task<ActionResult> AnnoyingLongRunningOperation(CancellationToken token)
{
    try
    {
        _logger.LogInformation("Calling long running operation");
        await ActualAnnoyingLongRunningOperationAsync(token);
        _logger.LogInformation("Done with long running operation");
    }
    catch (OperationCanceledException ex)
    {
        // handle ex
        _logger.LogError("Long running operation was cancelled");
    }
    return new OkObjectResult("Done!");
}
private async Task ActualAnnoyingLongRunningOperationAsync(CancellationToken token)
{
    for(int i=0;i<100;i+=2)
    {
        _logger.LogInformation($"Loop counter : {i}");
        await Task.Delay(100); // 100 important operations
    }
    token.ThrowIfCancellationRequested();
    // 100 other important operations
}

Again, after I initiated the request using Postman, I immediately hit cancel and this is how the application behaves now.

This time you can see that we have managed cancellation on our own terms, we have made sure the loop runs completely(could represent some necessary backend job etc) before cancellation is processed.

In both the cases, the task that was consuming needless server resources, was disposed from the pool.

Cancellation model is an easy and neat feature we should always look out for implementing in our projects and I hope this post gave you some insights.

Thank you for reading. Cheers!

Take a look at my other post Cancellation token multifold 😇 which talks about different mix and matches of cancellation token usage.

Individuals who are particular about their operating system, the editor they use, the way they use language constructs.

In this post, I am going to talk about how this craziness make code reviews even crazier. A real pain in the 🍑

Hello madness

Imagine 10 such individuals working on a project, everybody having their own set of preferences.

• Some prefer curly braces inline, some on next line.
• Some prefer a space before their if parenthesis and some don't.
• Some prefer space before and after their logical operations, some want them to be as compact as possible.
• You get the point..

As a reviewer, this is what you might end up seeing during code reviews. Where the hell is the actual code change? Also in my head -> BC 🤬 ???

While I have never played Waldo, I have seen memes on the internet, and it was the first thing that came to my mind when I got my first "crazy" pull request to review

Having consistent coding styles within a team is critical, every developer in the team should agree to use the language features the same way and that would make a reviewers life so much easy. But how do you enforce this? We'll take a look at that in our next section.

If you are still trying to figure what the code change was, here it is

Which again, does not make any sense, ++i and i++ within the context of a for loop is the same.

How do we enforce code consistency?

⭐EditorConfig⭐

This sleek little configuration file helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

😋 The best parts

• Multiple editor support.
• Works with a wide range of file types.
• These settings take precedence over your editor settings, which means that you can enforce consistent coding styles for your code base, settings that are specific to a repository.

🧱 To create one (I am going to use Visual Studio since that's my preferred IDE, your favorite IDE should have similar steps)

• All you have to do is right click on your project solution and add a new editorconfig This will pick all the editor settings you have in your Visual Studio instance and put it into a .editorconfig file inside your codebase. You can now push this to your remote repository. You should also get in touch with your fellow developers and make sure all are in agreement with the settings in place. As soon as they pull this file to their local, their preferences will be overridden.

• You could also go to Github, search for .editorconfig and take a look at how others have them created in their repositories.

😩 Caveat in Visual Studio
Editorconfig settings are not used automatically in Visual Studio, you will have to execute code cleanup each time. You could install extensions which would run code cleanup on save operation to overcome this. In my opinion Microsoft should make this a default behavior.

Editorconfig has made code reviews much more simpler for me and my team, makes it much more bearable now 😜, highly recommended.

Thank you for going through this post. I hope you found it useful. Cheers!

Extra Resources

• People arguing over curly braces inline vs newline🧐
• EditorConfig website

Here is a snippet from one of our sandbox application insights

The criminal

Transient failures

These failures can occur anytime, irrespective of the platform, the operating system, the programming language you are using to build your application. On a bad day, your application would simply not respond to key actions giving an impression to the end user that the system in place is highly unreliable.

There could be various reasons for such kind of failures, network issues, temporary unavailable services, server not able to respond in time(timeouts), some idiot spilled coffee on the server where your service is hosted etc.

With a paradigm shift towards cloud, these kind of errors have become more and more prominent. You are not going to get rid of them, but you could make your system more resilient and fault tolerant to such kind of failures.

💡 Note

They are often self-correcting, if the action is repeated again it is likely to succeed.

On your SSR enabled react app, you could notify the user to wait for sometime and try again, but microservices/components behind the scenes communicate with each other all the time, strategies have to be in-place beforehand, manual intervention just wont work in this case.

Polly

Enter Polly - A library that enables resilience and transient-fault-handling in your .NET application.

I am going to talk about 3 types of policies that I have used in my projects.

1. Fixed amount of retries but retry after an interval
2. Fixed amount of retries but retry with exponential backoff
3. Circuit breaker policy

Base setup

I exposed a throttled api which accepts only 2 requests in 10sec from a particular IP address. The API would respond with a 429 response code and a message. We will call this API continuously and see behaviour as a result of polly policies.

Behavior without any policy in place

💡 Note

In production environments, the behavior would be one failure and we are done, no further execution.

Fixed amount of retries but retry after an interval

⚙️ Setup in place
If response code is 429(too many requests) -> retry 3 times, wait for 2 sec before each retry.

var asyncRetryPolicy = Policy.HandleResult<HttpResponseMessage>(r => r.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
                   .WaitAndRetryAsync(
                    3,  
                    (retryNumber) => TimeSpan.FromSeconds(2),    
                    (exception, attemptTimespan) =>
                    {
                            Console.WriteLine($"[Polly] - Encountered an error: \"{ response.Result.Content.ReadAsStringAsync().Result}\" - Retrying after {attemptTimespan.TotalSeconds} sec.");
                    });
// run in loop
await asyncRetryPolicy.ExecuteAsync(async () => await httpClient.GetAsync("endpoint"));

Behavior with policy in place

Fixed amount of retries but retry with exponential backoff

⚙️ Setup in place
If response code is 429(too many requests) -> retry 3 times, 1st retry after 2 sec, second retry after 4 sec, third retry after 8 sec.

var asyncRetryPolicy = Policy.HandleResult<HttpResponseMessage>(r => r.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
                   .WaitAndRetryAsync(
                    3,    
                    (retryNumber) => TimeSpan.FromSeconds(Math.Pow(2, retryNumber)), 
                    (exception, attemptTimespan) =>  
                    {
                            Console.WriteLine($"[Polly] - Encountered an error: \"{ response.Result.Content.ReadAsStringAsync().Result}\" - Retrying after {attemptTimespan.TotalSeconds} sec.");
                    });
// run in loop
await asyncRetryPolicy.ExecuteAsync(async () => await httpClient.GetAsync("endpoint"));

Behavior with policy in place

Circuit breaker policy

⚙️ Setup in place
If response code is 429(too many requests) -> And it happens for 3 times consecutively, open the circuit for 10 sec so that no further API calls can go through.

var circuitBreakerPolicy = Policy.HandleResult<HttpResponseMessage>(r => r.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
           .CircuitBreakerAsync(3, TimeSpan.FromSeconds(10),
            (response, attemptTimespan) => 
            {
                       Console.WriteLine("[Polly] - Circuit is open for 10 sec.");
             },
             () =>
             {
                       Console.WriteLine("[Polly] - Circuit closed, requests flow normally.");
             });
// run in loop
await circuitBreakerPolicy .ExecuteAsync(async () => await httpClient.GetAsync("endpoint"));

Behavior with policy in place

In this post, I created a policy around the 429 http response code but you can write your policies around any kind of transient fault, or any kind of http response code(even treat 200 response as a failure 🙃 and do something about it) its all configurable. Polly provides a lot of resiliency options. Do check out their GitHub page here.

Thank you for going through this post. I hope you had some takeaways from it. Cheers!

Exploring Auth0 has made me realize one thing, it cant get simpler than this. Setting up identity with Auth0 was a delight, most of the time I didn't even need to look at the documentation (am I bragging or was the interface so user friendly?)

We will take a look at Stonks, a simple crypto listing app using Blazor WebAssembly and Auth0. The Blazor WebAssembly framework provides us with a frontend and a fake backend project, we will integrate Auth0 on both. From the backend logic we are going to make a call to coinapi.io to fetch a list of crypto currencies, narrow it down to a few thousand cryptos(why are there 12k+ cryptos?) and display them in our Blazor UI.

Apps and tools

• An IDE for .NET projects -> VS or VSCode or Rider

• Latest version of VS would automatically install .NET 5 for us

• Auth0 -> auth + identity

• Coinapi.io -> fetch list of cryptos

• https://jwt.io -> decrypt and analyze jwt tokens

TL;DR

I have attached some demo videos on the different connection types in Auth0, their setup and behaviour. Head over to the end of the post and take a peek.

Step1 - Bootstrap a blazor project

We will create the base Blazor project first.

1. Open command line

2. Go to the directory where you would want to create your projects, for me its
   cd StonksApplication

3. Bootstrap the projects using dotnet new blazorwasm --hosted, this command will create a Client, a Server, and a Shared project for us. The final structure should look like

.
├── Client           # Client project
│   ├── Pages   
│   ├── Shared
│   └── ...
├── Server           # Backend project
│   ├── Controllers                          
│   └── ...    
├── Shared           # Shared Library
│   └── ...
└── ...

4. Open the solution inside VisualStudio, inside cmdline start StonksApplication.sln

5. One VisualStudio is up, we will go ahead and run the application

For me the application loads at https://localhost:44304

Step2 - Auth0 setup

Once we have created and verified our Auth0 account, we will go ahead and setup the following

1. Application

2. Callbacks and CORS

3. API resources

4. Users

Setup Application
Since ours is a SPA we will select that type while creating.

Setup Callbacks and CORS
In the application settings page set the following values (the description against the setting tells us exactly they are meant for)

We use the same base url where our app is running
Allowed Callback URLs -> https://localhost:44304/authentication/login-callback (this is the default blazor middleware callback path)
Allowed Logout URLs -> https://localhost:44304
Allowed Origins (CORS) -> https://localhost:44304

Setup API resources
For our backend API, we will go ahead and create an API resource

Identifier -> https://localhost:44304/

The identifier(a.k.a audience) is critical, and in simple words mean "this API resource can be accessed by whosoever has this identifier".

Users
We will also go ahead and create one user under the User Management tab. We will use this user to login in our application.

Basic Auth0 configuration is now in place.

Step3 - Configure Blazor projects for Auth0

We will configure Auth0 for our projects

1. StonksApplication.Client

2. StonksApplication.Server

Configure Auth0 in Client project

For brevity we are going to take a look at the major code blocks/components only.

• Under wwwroot folder create a appsettings.json file.
  Add a json object which holds the following configurations from Auth0.

  

• Configure oidc authentication inside Program.cs.

public class Program
{
    public static async Task Main(string[] args)
    {
        ...
        builder.Services.AddOidcAuthentication(options =>
        {
            builder.Configuration.Bind("Auth0", options.ProviderOptions); 
            options.ProviderOptions.ResponseType = "code";
        });

        await builder.Build().RunAsync();
    }
}

Fetch and bind configuration from appsettings.json using builder.Configuration.Bind("Auth0", options.ProviderOptions);

Set the client to follow authorization_code flow using options.ProviderOptions.ResponseType = "code";. More on flows here.

Weird BLAZOR issue

As part of oidc configuration I should be also allowed to setup the audience property for my client, if missing, that would result into auth issues. More about it in later sections of the post, for now we move on.

• Under Pages folder create Authentication.razor which deals with login, logout authentication actions

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using Microsoft.Extensions.Configuration

@inject NavigationManager Navigation
@inject IConfiguration Configuration

<RemoteAuthenticatorView Action="@Action">
    <LogOut>
        @{
            var authority = (string)Configuration["Auth0:Authority"];
            var clientId = (string)Configuration["Auth0:ClientId"];
            Navigation.NavigateTo($"{authority}/v2/logout?client_id={clientId}&returnTo={Navigation.BaseUri}");
        }
    </LogOut>
</RemoteAuthenticatorView>
@code{
    [Parameter] public string Action { get; set; }
}

• Under Shared folder, create AccessControl.razor which will have a label for username, login and logout buttons.

@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject NavigationManager Navigation
@inject SignOutSessionStateManager SignOutManager

<AuthorizeView>
    <Authorized>
        Hello, @context.User.Identity.Name &nbsp;
        <button @onclick="BeginSignOut">Log out</button>
    </Authorized>
    <NotAuthorized>
        <button @onclick="BeginSignIn">Log in</button>
    </NotAuthorized>
</AuthorizeView>

@code{
    private async Task BeginSignOut(MouseEventArgs args)
    {
        await SignOutManager.SetSignOutState();
        Navigation.NavigateTo("authentication/logout");
    }
    private async Task BeginSignIn(MouseEventArgs args)
    {
        Navigation.NavigateTo("authentication/login");
    }
}

• Create a new Stonks.razor under Pages folder, this is the component where we will display the list of cryptos.
  Mark the page with Authorize attribute, this will force the user to login to view this page.

@page "/stonks"
@using StonksApplication.Shared
@attribute [Authorize]

Configure Auth0 in Server project

For brevity we are going to take a look at the major code blocks/components only

• Inside appsettings.json file add a json object which holds the following configurations from Auth0.

• Inside Startup.cs file of the project, setup authentication service

public void ConfigureServices(IServiceCollection services)
        {
            ...
            services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            }).AddJwtBearer(options =>
            {
                options.Authority = _configuration.GetValue<string>("Auth0:Authority");
                options.Audience = _configuration.GetValue<string>("Auth0:Audience");
            });
        }

Set DefaultAuthenticateScheme and DefaultChallengeScheme to Bearer. We want to use jwt tokens for auth inside our Server by default. Set the Authority and Audience values from appsettings.json as well.

This setup makes sure jwt(bearer token) validations are in place.

• Create a controller, mark the controller with the Authorize attribute. Only authorized requests will be allowed to go through from here on.

[ApiController]
[Route("v1/stonks")]
[Authorize]
public class StonksController : ControllerBase
{
       public StonksController()
        {
               ...
        }
}

With all of this in place, along with a few additional stuff like

1. Attaching access tokens to API calls from Client To Server

2. Coinapi setup inside Server, making API calls to coinapi to fetch list of cryptos

3. Weird Blazor issue resolution

4. Code cleanup

Here is the final result (the user was created while setting up Auth0)

I did spend more time exploring other connection types and super excited to share them too.
Had alot of wow moments along the way.

• Enterprise OIDC(extra setup was done on remote-identity-provider to allow calls from auth0 and a different user)

• Passwordless

• Social

Placeholder for video.

I had a lot of fun exploring Auth0, hope you had some takeaways from it.
In future I do plan to write about OIDC, OAuth and experiences in my blog. Thanks!

Additional resources

1. Github repo https://github.com/kndb-star/StonksApplication

2. Open issue in Blazor https://github.com/dotnet/aspnetcore/issues/20813

😡 Blazor issue

Calls to StonksApplication.Server kept on failing with a 401 httpstatus code.

After successful login, as a result of our oidc setup in StonksApplication.Client, we get a id_token and access_token from Auth0. We can clearly see something is wrong with the access token (they are usually bigger in length)

As part of our login flow we couldn't pass the audience in the login request. And that was the root of all my hair pulling.
Copy the access token, head to https://jwt.io, and decode the same

We can confirm the token is invalid.
From Auth0 docs, one way to solve this would be to set the audience value for all applications inside our Auth0 tenant. Basically, instead of the client requesting, we force set this.

We logout and login in our StonksApplication, and this time we see a different access token.

Copy the access token, head to https://jwt.io, and decode the same again

Our API calls are going through now.

1. a modular approach to building components

2. loose-coupling between its components.

Pre .NET Core, all types of web applications in the .NET ecosystem (MVC, WebAPI, etc) were heavily dependent on the System.Web library which in turn was tightly coupled to IIS. The library tried to do too many things, did a great deal of heavy lifting behind the scenes, most of which would end up being redundant, unwanted, or unchangeable.

Enter "Open Web Interface for .NET" a.k.a. OWIN

OWIN

From their website

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

OWIN specification helps create a decoupled layer that allows two frameworks with different object models to work together. Decoupling components would mean iterations would be independent, a plug-n-play option would enable small, lightweight, high-performance hosting of applications.

.NET Core fully supports OWIN specification, this allows .NET Core to be hosted on top of a OWIN compatible server/host or for other OWIN compatible components to run on top of .NET Core.

The specification also introduces something called middlewares. We will take a look at middlewares in .NET Core, the middleware pipeline, and leverage that to create a middleware of our own.

What is a middleware?

From OWIN specification

Middleware — Pass through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.

Middleware is a code-block/logic/component that is assembled into an application pipeline to handle requests and responses. Each component

1. Chooses whether to pass the request to the next component in the pipeline.

2. Can perform work before and after the next component in the pipeline.

Middlewares in .NET Core

There are different ways to setup Middlewares in .NET Core

1. Inline request delegates(which are middlewares) using Use, Run, Map

2. Custom middleware class

Use
Helps chain multiple request delegates. The next parameter represents the next delegate in the pipeline.

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Use(async (context, next) =>
        {
            // Do some work before calling the next middleware
            await next.Invoke();
            // Do some work after the next middleware execution completes
        });
        app.UseRouting();
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Run
Helps short-circuit the pipeline. Nothing gets executed beyond this.

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Allo!");
        });
        // nothing beyond this gets executed
        app.UseRouting();
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Map
Helps with conditional branching in the pipeline. Runs middlewares when conditions are met.

public class Startup
{
    private static void HandleMyRoute(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("I was forced here.");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        // a request with path "/myroute" will branch out
        app.Map("/myroute", HandleMyRoute);
        app.UseRouting();
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Custom middleware class
A cleaner approach, we write our middleware logic in a separate class and then use it in our pipeline using the UseMiddleware extension. The invoke method(which takes in the HtttpContext) is important here and this is where we have our middleware logic.

public class MyCustomMiddleware
{
    private readonly RequestDelegate _next;
    public MyCustomMiddleware(RequestDelegate next)
    {
        _next = next;
    }
    public async Task Invoke(HttpContext httpContext)
    {
        // Do some work before calling the next middleware  
        await next(httpContext);
        // Do some work after the next middleware execution completes
    }
}

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.UseRouting();
        app.UseAuthentication();
        app.UseAuthorization();
        // after authorization run MyCustomMiddleware
        app.UseMiddleware<MyCustomMiddleware>();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Our very own custom middleware

Let's create a custom middleware class of our own, use it in our middleware pipeline and see it in action.

Middleware class
Our middleware logic will catch unhandled exceptions, wrap them into a problem details object before sending back the response to the client.

public class CustomExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly bool _seeStackTrace;

    public CustomExceptionMiddleware(RequestDelegate next, bool seeStackTrace = false)
    {
        _next = next;
        _seeStackTrace = seeStackTrace;
    }

    public async Task Invoke(HttpContext httpContext)
    {
        try
        {
            await next(httpContext);
        }
        catch(Exception ex)
        {
            await HandleException(httpContext, ex);
        }
    }

    private async Task HandleException(HttpContext httpContext, Exception ex)
    {
        string details;
        if(_seeStackTrace)
        {
            details = ex.ToString();
        }
        else
        {
            details = "Exception was caught inside custom exception middleware.";
        }
        var responseProblemDetails = new ProblemDetails
        {
            Title = ex.Message,
            Detail = details,
            Type = "https://httpstatuses.com/" + (int)HttpStatusCode.InternalServerError
        };
        httpContext.Response.ContentType = "application/json";
        httpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
        await httpContext.Response.WriteAsync(JsonSerializer.Serialize(responseProblemDetails));
    }
}

Startup class
We will place the middleware at the start of the middleware pipeline so that it acts as an umbrella for all uncaught exceptions. EVERYTHING GETS CAUGHT

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        // we place our middleware at the start 
        app.UseMiddleware<CustomExceptionMiddleware>();
        app.UseRouting();
        app.UseAuthentication();
        app.UseAuthorization();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Controller
We expose a GET endpoint and explicitly throw an exception.

public class HashnodeController : ControllerBase
{
        [HttpGet("~/hashnode")]
        public int GetHashnodePostCount()
        {
            throw new ApplicationException("You shall not pass!");
            return int.MaxValue;
        }
}

Done with our setup, now it's time to see it in action.
As soon as we hit our /hashnode GET endpoint, in the error response we should start seeing our custom message wrapped as a problemdetails object.

A pretty neat way to make sure all uncaught exceptions are handled appropriately. Also helps declutter code from too many try-catch blocks.

Thank you for going through this post. I hope you found it useful. Cheers!

Additional resources

1. Read about OWIN specification.

2. Also take a look at project Katana, which contains a set of OWIN components built by Microsoft.

3. Read about problem details.