1. Introduction to dapr
2. Service Invocation
3. Publish-Subscribe pub/sub
4. State management
5. Hosting using AKS (Azure Kubernetes Services)

Distributed applications are composed of independent services. While each service should be stateless, some services must track state to complete business operations. Consider a shopping basket service for an e-commerce site. If the service can’t track state, the customer could loose the shopping basket content by leaving the website, resulting in a lost sale and an unhappy customer experience. For these scenarios, the state needs to be persisted to a distributed state store.

For that, we are going to add to our sample an example of a state store first using Redis .
Note: we are not going through best practices for creating a basket store for our website, we are just going to see how to use the state management.

in our last scenario, we have used the Service Invocation so our front app calls our API and so like that we get a list of cookies, now we are going to add an “Add” button in front of each cookie, and when the user clique on it, the ID of the cookie will be added to the basket (if you want to work on on the project you are welcome to contribute and add awesome stuff to it ).

First, let’s see what we are going to have :

You can download the source code from this link :

Now, how we work with state management.

How it works

First of all, and in order to work with the state we have to add a components folder that will contain few files that we are going to work with from state management to pub/sub and cron jobs.

Now , we need to create a yaml file : statestore.yaml .

ps: you can find the file when you install daper under  :  user\.dapr\components

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: redisstore
spec:
  type: state.redis
  metadata:
  - name: redisHost
    value: localhost:6379
  - name: redisPassword
    value: ""
   

The type of database is determined by the type field, and things like connection strings and other metadata are put in the .metadata section. Even though metadata values can contain secrets in plain text, it is recommended you use a secret store.
Here our store name is redisstore and we are going to use it later in our code sample.

Using the Dapr .NET SDK

Well as you may know it’s a combination of key/value ,this is how we store data here :

//saving a key of amount with data 5
await daprClient.SaveStateAsync<int> ("redisstore","amount",5);

//getting the value using the key "amount"
var amounttotal=await daprClient.GetStateAsync<int> ("redisstore","amount");

As you can see in the above sample, we are saving a combination of amount/5 and we are getting the value using the GetStateAsync method.

In our cookies sample, we want to save a list and its key is going to be CookiesList

var orderState = await _daprClient.
                    GetStateEntryAsync<List<Item>>("redisstore", "CookiesList");

in order to get to the data from the store we should use the: GetStateEntryAsync, passing as parameters the name of the store that we early have configured in the statestore.yaml , also we pass the key and in our case is CookiesList.

public async Task<IActionResult> AdddataAsync(Guid ID)
{
    Item _tem = new Item();
   
 
   //getting the state
    var orderState = await _daprClient.
            GetStateEntryAsync<List<Item>>("redisstore", "CookiesList");

    List<Item> CookiesList = new();
    if (orderState.Value == null)
    {
        _logger.LogInformation("CookiesList   Case not exist ");
        CookiesList.Add(_tem);
        await _daprClient.SaveStateAsync("redisstore", "CookiesList", CookiesList);
    }
    else
    {
        _logger.LogInformation("OrderState  Case exist ");
        CookiesList = orderState.Value;
        CookiesList.Add(_tem);
        await _daprClient.SaveStateAsync("redisstore", "CookiesList", CookiesList);
    }

    ViewData["OrderId"] = ID;
    return View("Thanks");
}

in our sample here, we are receiving an ID from the page and creating a list of items that will contain the list of ID’s , in case the CookiesList exists we are adding the item to it else we are going to create it using the first method.

Now like that have made sure everything is alright, how can we explore or see if the store has been created and how to retrieve the value using the key.

Exploring Redis

Well, there are many ways to explore the Redis store here that we have created and we are going to see a couple of them.

Using Docker :

using this sample docker command we can get into the store :

Docker run --rm -it --link dapr_redis redis redis-cli -h dapr_redis

Now as we are inside the store, how can we see our keys/values?

simple using this command :

keys *

As you can see, we can see our cookies list here,now in order to explore it we need to use the following command :

HGET "cookiesclient||CookiesList" data

In order to delete key/value we should use :

del key "cookiesclient||CookiesList"

Using Visual studio code  :

using visual studio code too we can explore the data after installing the Redis explorer plugin:

Also, there is other methods that we can use you can found them right here: https://docs.dapr.io/developing-applications/building-blocks/state-management/howto-get-save-state/

Retrieving the Data using the Dapr SDK

Now after we have saved our data to the store ,when we go to basket page we need to see the list of GUID that we have saved inside our list in order to get that list we should use :

var orderState = await _daprClient.
                                GetStateEntryAsync<List<Item>>("redisstore", "CookiesList");

now if the order state.Value.Count>0  that means we have data inside it and we can get it  like that and passe it to our view :

var orderList = orderState.Value;

Now in this part we have seen how to use the Save and get state using Redis , in the the Part 2 we are going to see how to use the Azure Cosmos DB as a backend state store .

Source code : https://bit.ly/3s5pz5C

1. Introduction to dapr
2. Service Invocation
3. Publish-Subscribe pub/sub
4. State management
5. Hosting using AKS (Azure Kubernetes Services)

In the previous part, we have created our API and we have seen how to use dapr to expose it, also we have seen how to use the dapr dashboard and also to use zipkin as  tracing system .

In this part, we are going to create an MVC project as a Front-end for our solution.

For that we are going to see step by step from adding dapr nuget package to consuming the service .

Creating the MVC Project

First of all we are going to add a new MVC project to the solution as the follow image below :

next we are going to create the same model that we have in our API inside Models folder .

Next thing and before doing anything we need to install our DAPR NUGET PACKAGE :

Install-Package Dapr.AspNetCore -Version 1.3.0

now we need to configure ConfigureServices by adding dapr :

services.AddControllersWithViews().AddDapr();

Also inside the Configure method we need to add :

app.UseCloudEvents();

CloudEvents receive every incoming request with the content type of “application/cloudevents+json” .

Now we can go on and start creating our methods.

public interface IBroRepository 
   {
       Task<IEnumerable<Cookies>> Getcookies();

   }

public class BroRepository : IBroRepository
  {
      private readonly HttpClient _httpClient;

      public BroRepository(HttpClient httpClient)
      {
          _httpClient = httpClient ?? throw new ArgumentNullException(nameof(httpClient));
      }

      public async Task<IEnumerable<Cookies>> Getcookies()
      {
          return await _httpClient.
                GetFromJsonAsync<IEnumerable<Cookies>>("/api/cookies");
      }
  }

As you can see inside the BroRepository we are calling the cookies API from the Getcookies() .

Now we need to register our service by adding a singleton and as you can see we are invoking an HTTP client that is calling the API using the app ID that we have created while running the service using dapr .

services.AddSingleton<IBroRepository, BroRepository>(_ => new BroRepository(DaprClient.CreateInvokeHttpClient("cookiesstoreapi")));

Now we can create our controller :

public class HomeController : Controller
  {
      private readonly ILogger<HomeController> _logger;
      private readonly IBroRepository _IBroRepository;

      public HomeController(ILogger<HomeController> logger, IBroRepository IBroRepository)
      {
          _logger = logger;
          _IBroRepository = IBroRepository;
      }

      public async Task<IActionResult> Index()
      {
          //logging info
          _logger.LogInformation("Entered Index method");
          var data = await _IBroRepository.Getcookies();
          //logging info
          _logger.LogInformation($"Returning data {JsonSerializer.Serialize(data)}");
          return View(data);
      }

 

  
  }

Next we add our view page :

@model IEnumerable<Cookies>
@{
    ViewData["Title"] = "Home Page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core and Dapr</a>.</p>
</div>

<table class="table">
    <thead>
        <tr>
            <th>GUID</th>
            <th>Name</th>
            <th>Date (C)</th>
            <th>Picture</th>
            
        </tr>
    </thead>
    <tbody>
        @foreach (var cookie in @Model)
        {
        <tr>
            <td>@cookie.ID</td>
            <td>@cookie.Name</td>
            <td>@cookie.Date</td>
            <td>
                <div style="margin: 0 auto; width: 90px">
                    <img src=@cookie.ImageUrl     alt="me" style="width: 90px" />
                </div>

            </td>

        </tr>
        }
    </tbody>
</table>

Next, we start the ASP.NET Core API , listening on HTTP port 5001, and dapr on port 50001,also we start the ASP.NET Core Client, listening on HTTP port 5002, and dapr on port 50002:

Ps: make sure Docker is up and dapr containers are running.

dapr run --app-id cookiesstoreapi --app-port 5001  --dapr-http-port 50001 dotnet run

dapr run --app-id CookiesClient --app-port 5002  --dapr-http-port 50002 dotnet run

As you can see by visiting the http://localhost:5002/ we can see our website up and running!

Dapr also supports the following features through HTTP/gRPC to implement the sidecar pattern:

• State management.
• Publish and subscribe.
• Resource bindings & triggers.
• Actor runtime.
• Distributed tracing.

1. Introduction to dapr
2. Service Invocation
3. Publish-Subscribe pub/sub
4. State management
5. Hosting using AKS (Azure Kubernetes Services)

In the previous part, we have introduced dapr  ,now we are going to start creating our services one by one for that and as a start  what we need is :

1. Make sure Docker is running and Dapr services too .
2. Have .Net  5 Insatlled
3. Have visual studio installed .

Creating the API :

First of all we are going to create and empty solution and name it as you want to , and than we are need to add a : ASP .NET WEB API project to the solution  or you can just type

dotnet new webapi

The full solution can be found at this link :  https://bit.ly/3s5pz5C

Now, you may run the solution by running the following command :

dotnet run

after that when we go to visit: http://localhost:3902/api/cookies we will get as return a list of cookies

Runing the API :

What we really want to do is to run the solution using Dapr for that and in order to expose the cookies api using the dapr sidecar we need to run the command :

dapr run --app-id cookiesstoreapi --app-port 5001  --dapr-http-port 50001 dotnet run

This may be a bit strange for you so let’s explain all the parts of this command :

• –app-id : each app/service must have a unique ID .
• –app-port :  in launch settings i changed the parameters so the app runs on port 5001 when I use dotnet run.
• –dapr-http-port : the port that dapr in listening to for this service.
• dotnet run : this is how we run dotnet applications

Now when we run this cmd we can still get our cookirs from http://localhost:5001/api/cookies but also now we can get them from the side car using : http://localhost:50001/v1.0/invoke/cookiesstoreapi/method/api/cookies .

http://localhost:<dapr-http-port>/v1.0/invoke/<app-id>/method/<method-name>

Discovering the Services :

using the follow command we can see the running services by dapr  :

dapr dashboard

On http://localhost:8080/ u will find dapr dashboard that will present to you the running services also the dapr components :

zipkin

When the dapr is working and by veryfing the runing containers, one of them is a Zipkin container, so what is zipkin ?

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data.

running: Docker ps will show us the following containers  :

as you can see zipkin is runing on port : 9411

Zipkin let you trace your services and show you all the dependencies and we will see that in the next part .

1. Introduction to dapr
2. Service Invocation
3. Publish-Subscribe pub/sub
4. State management
5. Hosting using AKS (Azure Kubernetes Services)

Introduction to dapr .

Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge. Dapr embraces the diversity of all programming languages and developer frameworks and simplifies building applications such as the e-commerce example.

Dapr consists of a set of building blocks accessed by standard HTTP or gRPC APIs that can be called from any programming language. These building blocks empower all developers with proven, industry best practices and each building block is independent; you can use one, some, or all of them in your applications. In addition, through the open source project, we welcome the community to add new building blocks and contribute new components into existing ones. Dapr is completely platform agnostic, meaning you can run your applications locally, on any Kubernetes cluster, and other hosting environments that Dapr integrates with. This enables developers to build microservice applications that can run on both the cloud and edge with no code changes.

With dapr you can  build applications with any language and any framework by calling Dapr building blocks over standard APIs :

Portability does also extend beyond the hosting environment – while Dapr is an initiative started by Microsoft, it can also run on Kubernetes on-premise or in the cloud: Microsoft Azure, Amazon AWS, Google GCP, or any other cloud vendor…

building blocks

Dapr provides several building blocks that microservice application developers can adopt selectively, based on their needs:

• Service invocation: Using service invocation, your application can reliably and securely communicate with other applications using the standard gRPC or HTTP protocols.
• State management: Using state management, your application can store data as key/value pairs in the supported state stores (we will see in a further blog post) .
• Publish & subscribe messaging: The publish/subscribe pattern allows microservices to communicate with each other using messages. The producer or publisher sends messages to a topic without knowledge of what application will receive them. This involves writing them to an input channel. Similarly, a consumer or subscriber subscribes to the topic and receives its messages without any knowledge of what service produced these messages.
• Bindings: Using bindings, you can trigger your app with events coming in from external systems, or interface with external systems.
• Actors: The actor pattern describes actors as the lowest-level “unit of computation”. In other words, you write your code in a self-contained unit (called an actor) that receives messages and processes them one at a time, without any kind of concurrency or threading.
• Observability: Dapr enables the developer and operator to observe the behavior of the system services and applications without having to instrument them.
• Secrets management: It’s common for applications to store sensitive information such as connection strings, keys and tokens that are used to authenticate with databases, services and external systems in secrets by using a dedicated secret store.

installing dapr :

Well, before we go any further with dapr , we need first to install it and for so we need a couple fo things to do :

• Dapr requires Docker locally on your development environment, therefore make
  sure you have it installed : https://docs.docker.com/install
• Installing Dapr CLI :The Dapr CLI allows you to setup Dapr on your local dev machine or on a Kubernetes cluster, provides debugging support, launches and manages Dapr instances.

To install the Dapr CLI :

powershell -Command "iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1 | iex"

In order to verify that dapr have been installed we need to check the installation with this command:

dapr

Now that you have the Dapr CLI installed, it’s time to initialize Dapr on your local machine using the CLI.

Dapr runs as a sidecar alongside your application, and in self-hosted mode this means it is a process on your local machine. Therefore, initializing Dapr includes fetching the Dapr sidecar binaries and installing them locally.

make sure that docker is runing and open the terminal to run the follow cammand :

dapr init

Now you can verify the installed version of dapr using :

dapr --version

Now one more thing we need to check is the containers are runing well :

Now everything seems to be well-installed, the next thing we are going to do is to build a .Net application using the Service invocation Block.

For that and in order to follow this series , you need to make sure you have .Net installed (we will be working with .Net 5.0 ) and you may need to install visual studio or visual studio code.