Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6

This is the sixth part of Building Microservice Applications with Azure Container Apps and Dapr. The topics we’ll cover are:

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – (This Post)
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Azure Container Apps Async Communication with Dapr Pub/Sub API

In this post, we will introduce a new background service which is named “ACA-Processer Backend” according to our architecture diagram. This new service will be responsible for sending notification emails to task owners to notify them that a new task has been assigned to them. We can do this in the Backend API and send the email right after saving the task, but we want to offload this process to another service and keep the Backend API service responsible for managing tasks data only.

To do this the right way, we need to decouple the 2 services from each other, so this means we are going to rely on the Publisher-Subscriber pattern (Pub/Sub Pattern).
The main advantage of this pattern is that it offers loose coupling between services, the sender/publisher of the message doesn’t know anything about the receiver/consumers, even you can have multiple consumers consuming a copy of the message in a totally different way, think of adding another consumer which is responsible to send push notification for the task owner (If we have a mobile app channel :))

The publisher/subscriber pattern relies on a message broker which is responsible for receiving the message from the publisher, storing the message to ensure durability, and delivering this message to the interested consumer(s) to process it. There is no need for the consumers to be available when the message is stored in the message broker, consumers can process the messages at a later time when they are available. The below diagram gives a high-level overview of how the pub/sub pattern works

The source code for this tutorial is available on GitHub. You can check the demo application too.

Overview of Dapr Pub/Sub API

If you implemented the Pub/Sub pattern before, you already noticed that there is a lot of plumbing needed on the publisher and subscriber components in order to publish and consume messages, as well each message broker has it is own SDK and implementation, so you need to write your code in an abstracted way to hide the specific implementation details for each message broker SDK and make it easier for publisher and consumers to re-use this. What Dapr offers here is a building block that significantly simplifies implementing pub/sub functionality.

In very simple words, the Dapr pub/sub building block provides a platform-agnostic API framework to send and receive messages. Your producer/publisher services publish messages to a named topic. Your consumer services subscribe to a topic to consume messages.

To try this out we can directly invoke the Pub/Sub API and publish a message to Redis locally, if you remember from this post once we initialized Dapr in a local development environment, it installed Redis container instance locally, so we can use Redis locally to publish and subscribe to message. If you navigate to the path “<UserProfile>\.dapr\components” you find a file named “pubsub.yaml”. Inside this file, you will see the properties needed to access the local Redis instance. The publisher/subscriber brokers template component file structure can be found on this link.

I want to have more control and provide my own component name, so let’s create a pub/sub component file in our components folder, so go ahead and add a new file named “dapr-pubsub-redis.yaml” under the folder “components”. The content of the file will be as the below:

To try out the Pub/Sub API, run the Backend API from VS Code by running the below command or using the Run and Debug tasks we have created in the previous posts. Don’t forget to include the property “–components-path” if you are using dapr run from PowerShell.

Now let’s try to publish a message by sending a POST request to http://localhost:3500/v1.0/publish/taskspubsub/tasksavedtopic with the below request body, don’t forget to set the “Content-Type” header to “application/json”

Looking at the endpoint, we can break it into the following:

• The value 3500: is the Dapr app listing port, it is the port number upon which the Dapr sidecar is listening
• The value taskspubsub: is the name of the selected Dapr pub/sub-component.
• The value tasksavedtopic: is the name of the topic to which the message is published

If all is configured correctly, you should receive HTTP response 204 from this endpoint which indicates that the message is published successfully by the service broker (Redis) into the topic named “tasksavedtopic”. You can check that topic is created successfully by using the Redis Xplorer extension in VS Code.
Note: Some Service Brokers allows the creation of topics automatically when sending a message to a topic which is not been created before, that’s the clarification of why the topic “tasksavedtopic” is created automatically.

Right now those published messages are stored in the message broker topic doing nothing as we don’t have any subscribers bound to the service broker on the topic “tasksavedtopic” which is interested to consume and process those messages. So let’s add a consumer to consume the message.

Setting up the Backend Background Processer Project

Step 1: Create a Web API Project

Now we will add a new ASP.NET Core Web API project named “TasksTracker.Processor.Backend.Svc”, Configuration will be as the image below, check “Enable Docker” as we are going to containerize the application and deploy it to ACR, make sure “Linux” is selected for the Docker OS setting.

Step 2: Add Models (DTO)

Now we will add the DTO which will be used to deserialize the published message, so add a new file named “TaskModel.cs” under a new folder named “Models” and paste the code below:

Step 3: Install Dapr Client NuGet package

Now we will install Dark SDK for .NET Core in the Backend Background Service to be able to subscribe to the service broker topic in a programmatic way, to do so, open the .csproj file of the project “TasksTracker.Processor.Backend.Svc.csproj” and add the below NuGet package

Step 4: Create an API endpoint for the consumer to subscribe to the topic

Now we will add an endpoint that will be responsible to subscribe to the topic in the message broker we are interested in, this endpoint will start receiving the message published from the Backend API producer, to do so, add a new controller named “TasksNotifierController.cs” under “Controllers” folder and use the code below:

What we have implemented here is the following:

• We have added an action method named “TaskSaved” which can be accessed on the route “api/tasksnotifier/tasksaved”
• We have attributed this action method with the attribute “Dapr.Topic” which accepts the Dapr pub/sub component to target as the first argument, and the second argument is the topic to subscribe to, in our case “tasksavedtopic”
• The action method expects to receive a “TaskModel” object.
• Now once the message is received by this endpoint, we can start out business logic to trigger sending an email (more about this next) and then return 200 ok responses to indicate that the consumer processed the message successfully and the broker can delete this message.
• If anything went wrong during sending the email (i.e. Email service not responding) and we want to retry processing this message at a later time, we return 400 bad request, this will inform the message broker that the message needs to be retired based on the configuration in the message broker.
• If we need to drop the message as we are aware it will not be processed even after retries (i.e Email to is not formatted correctly) we return a 404 not found response, this will tell the message broker to drop the message and move it to dead-letter or poison queue.

Now you will ask yourselves how the consumer was able to identify what are the subscriptions available and on which route they can be found, the answer for this that at startup on the consumer service, the Dapr runtime will call the application on a well-known endpoint to identify and create the required subscriptions. The well-known endpoint can be reached on this endpoint: http://localhost:<appPort>/dapr/subscribe
When you invoke this endpoint, the response will contain an array of all available topics for which the applications will subscribe. Each includes a route to call when the topic receives a message, this was generated as we used the attribute “Dapr.Topic” on the action method “api/tasksnotifier/tasksaved”. That means when a message is published on the Pubsubname “taskspubsub” on the topic “tasksavedtopic”, it will be routed to the action method “/api/tasksnotifier/tasksaved” and will be consumed in this action method.

In our case, a sample response will be as below:

In this link, you find a detailed diagram of how the consumers will discover and subscribe to those endpoints.

Step 5: Register Dapr and Subscribe Handler at the Consumer startup

Open file “Programs.cs” in the project “TasksTracker.Processor.Backend.Svc” and paste the code below

What we’ve done is the following:

• In line 11, the extension method “AddDapr” registers the necessary services to integrate Dapr into the MVC pipeline. It also registers a “DaprClient” instance into the dependency injection container, which then can be injected anywhere into your service. We will see how we are injecting DaprClient in the controller constructer later on.
• In line 19, the extension method “UseCloudEvents” adds CloudEvents middleware into the ASP.NET Core middleware pipeline. This middleware will unwrap requests that use the CloudEvents structured format, so the receiving method can read the event payload directly. You can read more about CloudEvents here. (Specs to describing evet data in a common and standard way)
• In line 23, in order to make the endpoint http://localhost:<appPort>/dapr/subscribe available for the consumer so it responds and returns available subscriptions we need to configure the consumer to do this by calling “MapSubscribeHandler”. When this endpoint is called, it will automatically find all WebAPI action methods decorated with the “Dapr.Topic” attribute and instruct Dapr to create subscriptions for them.

With all those bits in place, we are ready to run the publisher service “Backend API” and the consumer service “Backend Background Service” and test pub/sub pattern end to end, to do so, run the below commands in PowerShell console, ensure you are on the right root folder.

Notice that we gave the new Backend background service a Dapr App Id with the name “tasksmanager-backend-processor” and a Dapr HTTP port with the value “3502”.

Let’s try to publish a message now from the Backend API similar to what we have done earlier by sending this POST request

And keep eye on the terminal logs of the Backend background processor, you will see that the message is received and consumed by the action method “api/tasksnotifier/tasksaved” and an information message is logged in the terminal to indicate the processing of the message. It should be similar to the below image:

Hint: You can use VS Code Dapr extension which we installed in this post to publish the message directly, it will be similar to the below image

Step 6: Update VS Code tasks and launch configuration files

In order to be able to run the 3 services together and debug them in VS Code, we need to update the files tasks.json and launch.json to include the new service we have added, it will be similar to what we have done exactly in this post. You can use this file to update tasks.json and this file to update launch.json files.

Use the Dapr .NET Client SDK to publish messages

Step 1: Update Backend API to publish a message when a task is saved

Now we need to update our Backend API to publish a message to the message broker when a task is saved (a new task is added or an existing task assignee has changed when updating it).

To do this open file named “TasksStoreManager” under the project “TasksTracker.TasksManager.Backend.Api” and update the file as the following:

Notice the highlighted rows and the new method “PublishEventAsync” added to the class, all we have to do is to call the method “PublishEventAsync” and pass the Pub/Sub name, in our case I named it “dapr-pubsub-servicebus” as we are going to use Azure Service Bus as a message broker in the next step (Feel free to use any name you want), and the second parameter “tasksavedtopic” is the topic name the publisher going to send the task model to it, that’s It for publishing, no extra changes needed to start publishing async messages from the Backend API.

Step 2: Update Backend Background Processor to consume messages and send actual email using SendGrid

Open controller named “TasksNotifierController.cs” under Backend Processor Project and update the controller as the code below

What we’ve done In the code above is the following:

• We’ve updated the attribute “Dapr.Topic” to use the same Pub/Sub component name used in the publisher “dapr-pubsub-servicebus”. Then we add a new method that is responsible to consume the proceed message, taking the assignee email, and trying to send an email using SendGrid API.
• We are returning 200 Ok if the SendGrid was able to send the email successfully, and we are returning 400 Bad request if the SendGrid failed to send the email, this will allow the consumer service to re-try processing the message again.
• Don’t forget to add the NuGet package named “SendGrid” version “9.28.1” to the Backend processor project, as well we are reading the “SendGrid:ApiKey” from AppSettings, we will read this value from environment variables once we deploy this service to Azure Container Apps. So open the file named “appsettings.json” and add the below config:

Use Azure Service Bus as a Service Broker for Dapr Pub/Sub API

Now we will switch our implementation to use Azure Service Bus as a message broker, Redis worked perfectly for local development and testing but we need to prepare ourselves for the cloud deployment, to do so we need to create Service Bus Namespace, then a topic.

Step 1: Create Azure Service Bus Namespace and a Topic

You can do this from Azure Portal or use the below PowerShell command to create the services. I will assume you are using the same PowerShell session from the previous posts so variables still hold the right values, you need to change the namespace as this one is already used by me.

Step 2: Create Dapr Pub/Sub API Component file for Azure App Service deployment

Go ahead and add a new file named “containerapps-pubsub-svcbus.yaml” under the folder “aca-components”and paste the code below:

Notice that we are not setting the Azure Service bus connection string here, this will not be secure, we are using “secretRef” which will allow us to set the actual “sb-root-connectionstring” after we deploy this component to the Azure Container Environment. So this key will not be stored in the source code by mistake.

As well we’ve used the “Scopes” property to limit access to only those 2 applications (Frontend App is not concerned with Pub/sub pattern), so using the scopes property will help us to achieve this. More on scopes on this link.

Deploy the Backend Background Processer and the Backend API Projects to Azure Container Apps

Step 1: Build the Backend Background Processer and the Backend API App images and push them to ACR

As we have done previously we need to build and deploy both app images to ACR so they are ready to be deployed to Azure Container Apps, to do so, continue using the same PowerShell console and paste the code below (Make sure you are on directory “TasksTracker.ContainerApps”):

Step 2: Add Azure Service Bus Dapr Pub/Sub Component to Azure Container Apps Environment

We need to run the command below to add the yaml file “.\aca-components\ccontainerapps-pubsub-svcbus.yaml” to Azure Container Apps Environment, to do so run the below PowerShell command:

Notice that we set the component name “dapr-pubsub-servicebus” when we added it Container Apps Environment.
Once the command completes and from the Azure Portal, navigate to your Container Apps Environment, select “Dapr Components”, then click on “statestore” component, and provide your Azure Service Bus connection string in the Secrets text box value for the secret “sb-root-connectionstring” and click “Edit” button. It will be similar to the below image

Step 3: Create a new Azure Container App to host the new Backend Background Processor

Now we need to create a new Azure Container App, we need to have this new container app with those capabilities in place:

• Ingress for this container app should be disabled (No access via HTTP at all, this is a background processor responsible to process published messages).
• Dapr needs to be enabled.
• Setting the value of SendGrid API in the secrets store and referencing it in the environment variables.

To achieve the above run the below PowerShell script and notice how we removed the Ingress property totally Ingress is disabled for this Container App:

Step 4: Deploy new revisions of the Backend API to Azure Container Apps

As we’ve done this multiple times we need to update the Azure Container App hosting the Backend API with a new revision so our code changes for publishing messages after a task is saved is available for users, to do so run the below PowerShell script:

With this in place, you should be able to test the 3 services end to end and should receive a notification email to the task assignee email, the email will look like the below

In the next post, we will cover how are going to use Dapr binding with Azure Container Apps, stay tuned and happy coding!

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

References:

• The Dapr publish & subscribe building block