Most companies today are Software companies in a sense that their business is heavily dependent on Software components built in-house or acquired to other companies.

Modern Software is usually built in a global and distributed way, and leverages several technologies and platforms to make sure businesses have a broader reach and access to more customers. This increases the systems complexity and makes it harder to maintain them in the long run.

One of the main challenges that teams face is getting stuck to decisions they make. If you choose a Cloud or Database provider you are typically going to stay with it for a long time. This fact is usually driven by the complexity of moving between platforms and it is a major factor when making architectural and platform decisions.

The role of Dapr is to facilitate the process of building distributed applications by abstrating the platform components. This makes it almost seamless to move between providers without code changes. It also simplifies the code required to integrate with databases, pubsub platforms and others, while enforcing best practices for distributed platforms such as retrying failed requests automatically.

With this demo we try to cover some of the aspects and complexities of event-driven systems and show how Dapr overcomes them.

This demo is provides a frontend application for easy interaction with the platform. In the frontend application you can choose to go through the customer experience or employee experience (work in progress). As a customer you can select food and drinks from a list of items and submit your order. After the order is submitted the employee will work on completing the order and completing the request for you.

The backend side of the application is a distributed system built in a microservices approach with pluggable components provided by Dapr which makes it easier to swap providers without code changes.

This provides great developer experience as you can use some components locally but other providers when deploying to your production environment (e.g. Azure Kubernetes Services cluster in Microsoft Azure).

When you submit and order from the frontend component (not using Dapr) a request is sent to the order management service that publishes a message to a pubsub topic with the order details.

This message is then processed by the order-processor service that is active listening to events sent to a topic. This service checks if the order information received is already being processed or not to ensure idempotency. This is very important to ensure that we don't process the same order more than once when a potential retry occurs.

Once the order is validated, the order information is persisted in the state store for employee processing.

The stored information can be queried or updated from the order management service.

The order management service also leverages a secret store component that contains secrets to be used at runtime. This component allows developers to abstract the platform where they are storing their secrets in (e.g Azure Key Vault, Dapr local secret store, ...).

Now that you understand how we built the demo, give it a go!

This repository contains all the components necessary to deploy locally or to Azure Kubernetes Service in Microsoft Azure. Follow the steps below to deploy the application.

1. Fork and Clone project locally Open the project and fork it to your own GitHub account.

   Then clone the project locally.

   git clone https://github.com/[YOUR-GITHUB-ACCOUNT]/dapr-cafe

2. Install Dapr cli (if you haven't done so)

3. Iniatilize Dapr in your local environment

4. Run all services with multi-app run In your project root run the following command to deploy all services and components required to run you application.

    dapr run -f . 

This will run your services and expose their logs in the terminal automatically.

To deploy in Microsoft Azure there are a few manual steps that are not covered in this repository. Make sure you do them before deploying the environment to Microsoft Azure.

1. Create AKS cluster

2. Create Azure Container Registry

3. Create Azure Static Web App

4. Create Azure CosmosDB (SQL API) to be used as our state store

5. In AKS

   1. Deploy Redis

   2. Create secrets required by components

      REDIS

      kubectl create secret generic redis-secret --from-literal=REDIS_PASSWORD="[YOUR-REDIS-PASSWORD]" 

      COSMOS DB

      kubectl create secret generic cosmosdb-creds --from-literal=COSMOSDB_URL="[YOUR-COSMOSDB-URL]" --from-literal=COSMOSDB_MASTER_KEY="[YOUR-COSMOSDB-KEY]" --from-literal=COSMOSDB_DATABASE="[YOUR-COSMOSDB-DATABASE]" --from-literal=COSMOSDB_COLLECTION="[YOUR-COSMOSDB-COLLECTION]"

6. On GitHub, add the following secrets used by GitHub actions for Azure Container Registry and Kubeconfig.

**Warning:** Secret names are case sensitive. Make sure you get the casing right to avoid errors when running GitHub actions.

7. Run GitHub action to deploy services and components to Azure.

The existing GitHub action can be triggered by pushing any code change to the main branch.

8. After deployment is successful, go to azure static apps and open browser

I hope you had fun playing with Dapr locally and you were able to deploy it to Azure and see that you can easily swap the components with zero code changes and it still worked.