DEV Community: Marc Duiker

A free, open-source Dev Dashboard for local Dapr development

Marc Duiker — Mon, 20 Jul 2026 15:25:25 +0000

Developing Dapr applications means you're dealing with multiple apps and sidecars, looking at several terminals for log output and component files. There is now a free, open-source Dev Dashboard that brings it together in one live view. It runs as a single binary and auto-discovers apps started with dapr run, .NET Aspire, Docker Compose, or Testcontainers.

See everything Dapr at a glance

The dashboard shows your running apps with health, ports, and process IDs, plus their loaded components, actor types, and pub/sub subscriptions. You can also tail sidecar and application logs in the same window, with level coloring and keyword highlighting.

Debug workflows without guesswork

For Dapr Workflows you can list executions across your apps, inspect event history and input/output per step, and terminate or purge instances. The data is read straight from your local state store, so you see the real state rather than a copy.

Build components and policies in a UI

Two guided builders generate Dapr component and resiliency YAML from the full catalog, so you can skip hand-editing files.

Download & Install

You can view the project on GitHub: https://github.com/diagridio/dev-dashboard

You can install the dashboard directly via the terminal:

Install (macOS / Linux)

curl -sSL https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.sh | sh

Install (Windows, PowerShell)

iwr -useb https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.ps1 | iex

Give it a try when you're developing and testing your Dapr applications. Once you have it running, come share how it works for you in the Dapr Discord. If you hit a bug or have an idea to make it better, open an issue on the dev-dashboard repository.

Making Microsoft Agent Framework agents durable with Dapr Workflow

Marc Duiker — Tue, 07 Jul 2026 15:48:50 +0000

LLM calls are slow, costly, and non-deterministic, so a multi-agent app that crashes halfway through wastes time and money re-running everything. Dapr Workflow turns a set of MAF agents into a durable, fault-tolerant app that resumes from saved state and replays completed agent calls instead of hitting the LLM again.

There's a new free Dapr University track uses PrDigest, a .NET Aspire app that triages open Dapr PRs. You'll inspect the AppHost configuration, MAF agent registration, and the agent orchestration.

Try the track here.

Keep your Dapr Agent's answers current with a Tavily web search tool

Marc Duiker — Tue, 16 Jun 2026 13:46:15 +0000

LLMs are frozen at training time, so they return confident answers that may already be out of date. This free, self-paced Dapr University track shows you how to close that gap in Python by giving an agent access to the live web.

You'll build an expert agent with Dapr Agents that calls a Tavily search tool to fetch current information, then reasons over those results through the provider-agnostic Dapr Conversation API. Combining tool calls with agent reasoning keeps answers grounded in today's data.

This university track requires an OpenAI API key and a free Tavily key.

Start the free track here!

New Dapr University track for Dapr Workflows in .NET with Aspire

Marc Duiker — Tue, 19 May 2026 08:46:28 +0000

A free, self-paced track that walks through Dapr Workflow in a .NET Aspire solution. Runs in your browser and connects to a cloud-based sandbox, so there's nothing to install locally.

The new learning track covers:

Scaffolding an Aspire solution and adding the Dapr Workflow NuGet packages
Fan-out / fan-in workflow with parallel activities and a conditional follow-up
Dapr state store components for durable workflow state
Triggering workflows via HTTP and inspecting them in the Diagrid Dev Dashboard

Start the track at Dapr University.

State of Dapr 2026 report is out

Marc Duiker — Thu, 30 Apr 2026 09:18:52 +0000

The 2026 State of Dapr report is out. Workflow API usage doubled year over year. 34% of developers are building AI agents on Dapr, 28% already in production. Durable workflows and reliable agents on one runtime.

Download the report now to get all the insights: https://www.diagrid.io/reports-and-ebooks/state-of-dapr-2026?utm_source=dev-to&utm_medium=social

Webinar: Build Reliable Agentic Apps with Aspire, MAF, and Catalyst

Marc Duiker — Tue, 28 Apr 2026 16:23:18 +0000

TL;DR: Register here for the webinar on May 7th.

Join Marc Duiker and Whit Waldo for a live webinar on building reliable agentic applications in .NET.

Agentic apps look impressive in a demo, but most struggle the moment a tool call fails or a long-running task needs to survive a restart. The Microsoft Agent Framework by itself does not solve this. In this session you will see how three tools work together to close that gap: Aspire for local orchestration and observability, the Microsoft Agent Framework for building agents, and Diagrid Catalyst for durable execution and state.

If you are a .NET developer exploring agentic AI, this webinar will give you a clear picture of the moving parts.

📅 May 7th
🕑 8:00 AM PDT / 17:00 CEST

Register here

Who should attend
This session is for .NET developers who are building or planning to build agentic applications and want to take them beyond the demo stage. No prior experience with Aspire, MAF, or Catalyst is required.

What you will learn
By the end of the session you will understand:

Where reliability tends to break in agentic apps, including failed tool calls, timeouts, and long-running tasks that need to survive restarts
How Aspire improves local development and observability for distributed .NET apps
How the Microsoft Agent Framework helps you define and compose agents in .NET
How Diagrid Catalyst adds durable execution so your agents keep running through crashes, retries, and deployments
How the three fit together in a single project

Registration is free. Everyone who signs up will receive the recording after the event.

Join the Diagrid Catalyst AWS Hackathon!

Marc Duiker — Mon, 29 Apr 2024 08:13:50 +0000

We are excited to invite you to the Diagrid Catalyst AWS Hackathon—a four-week, virtual event where you can unleash your creativity and showcase your coding skills by building or modernizing a cutting-edge application using the powerful Diagrid Catalyst platform. Get ready to collaborate, compete, and win cash prizes! Register now.

What is Diagrid Catalyst?

Diagrid Catalyst is a Developer API platform providing a brand-new approach to distributed application development. Using the Catalyst APIs, powered by the Dapr open source project, developers can overcome the complexity of rewriting common software patterns and achieve higher productivity by offloading infrastructure concerns from their code to Catalyst.

Say hello to making API calls from any platform, in any language to build modern, cloud-applications with ease. This hackathon is your chance to explore the potential of Diagrid Catalyst while bringing your solution ideas to life! For more on Catalyst, watch our most recent webinar for a platform overview and API deep dive.

Why Participate?

Join the Diagrid Catalyst Hackathon to:

Innovate with an Emerging Product: Explore the ways Diagrid Catalyst can expedite your development process by building an application to solve real-world challenges.
Collaborate with Peers: Connect with fellow developers, designers, and entrepreneurs. Collaborate, share ideas, and learn from each other's experiences.
Enhance Your Skills: Sharpen your application development and architecture skills using the coding languages of your choice and deploying your solution on Amazon Web Services.
Win Prizes: Compete for impressive cash prizes! We have rewards lined up for the most exceptional projects and for providing product feedback. ‍ All participation is evaluated based on the criteria in the Hackathon Rules, Terms & Conditions.

What to Build?

Build or update an open-source microservice-based software solution utilizing at least two Diagrid Catalyst APIs. The solution should be composed of multiple application services and either be newly written or significantly enhanced to utilize Diagrid Catalyst. The solution should be architected using AWS infrastructure and hosting services. The solution must align with one of the areas below:

Polyglot compute/ Cross-platform service discovery: Application services are deployed to different AWS hosting platforms, which interact via the Catalyst APIs.
Stateful business process orchestration: Application services are instrumented as part of a Dapr Workflow using the Dapr Workflow authoring SDK paired with the Catalyst Workflow API.
Serverless architecture: Application services are optimized to run on AWS PaaS/SaaS services, which abstracts infrastructure concerns and enables high-scalability.

Hackathon Timeline

Registration Open: April 19th 2024
Project Submissions Open: May 10th 2024
Feedback Submissions Open: May 24th 2024
Registration Closes: May 17th 2024
Project Submissions Deadline: June 7th 2024
Feedback Submissions Deadline: June 14th 2024
Location: Virtual Only

Catalyst Reference Apps

Looking for inspiration? See below for a couple of sample projects we’ve built using Diagrid Catalyst. More samples, including an AWS-specific reference, will be available to participants on the Hackathon site.

Tetris Game

The classic “blocks falling from the sky” game! The solution consists of two services:

A Python Flask user service which serves the JavaScript/HTML front-end for the user sign up and leaderboard and handles user state management and leaderboard updates.
A game service written in Go, which serves the JavaScript/HTML frontend for the game itself and manages the game session lifecycle.

These two services need to manage state and communicate to ensure games are started with the appropriate users, and user profiles are updated with the game results. The service interaction and data storage is all implemented using the APIs provided by Catalyst. Read the blog post.

Pizza Store Management System

A distributed pizza store with Catalyst APIs. The solution comprises two .NET microservices, two serverless JavaScript functions and a Vue front-end. The applications depend on Diagrid Catalyst as the serverless API layer to connect to the underlying data and messaging infrastructure. Read the blog.

How to Participate?

Participation is straightforward:

Register: Submit a registration request form for the hackathon. Eligible participants will receive a direct invite to the Hackathon site, hosted on Devpost. Accept your invitation to Devpost and click the blue “Register” button on the Hackathon landing page to register.
Create a project: Create a project to frame out your hackathon solution ideas for others to see and potentially join in to help execute. You have a few options when it comes to projects:
1. Create a closed project to participate as an individual.
2. Create an open project to enable other Hackathon participants to join you in your mission. You can even choose to invite people to participate in your project.
3. Join an existing, open project if one is available and intrigues you.
Learn: Join our ongoing Catalyst webinar series or watch on-demand.
Build: Develop your application using Diagrid Catalyst. Let your creativity shine, and don't forget to integrate innovative features.
Submit: Submit your project with the required deliverables by the deadline, June 7

For more information on resource access, project requirements and judging criteria, view the Hackathon Rules, Terms & Conditions.

Prizes

We have exciting cash prizes up for grabs! Prizes range from a Grand Prize of $2000 to Runner-up Prizes of $1000 each and Bonus Prizes from $250-$500! Get swag for participating & provide valuable product feedback for the chance to win another $100.

If you participate in the hackathon, you are also eligible for a $100 referral bonus for spreading the word! Share the Hackathon details with your friends and encourage them to sign up. The participant with the most referrals wins!

Get Ready to Hack

Don’t miss this unique opportunity to explore Diagrid Catalyst, build innovative apps, and compete for cash prizes. Whether you're a seasoned developer or a curious beginner, the Diagrid Catalyst Hackathon is your time to shine.

Building a distributed pizza store in .NET with serverless Dapr APIs

Marc Duiker — Thu, 01 Feb 2024 10:57:11 +0000

Intro

When developers build distributed systems, they need to think about cross-cutting concerns such as security, observability, and resiliency. Developers also write a lot of glue code to orchestrate services, create long-running and durable workflows, and connect to external resources, such as message brokers and state stores.

Dapr, the Distributed Application Runtime, is ideal for building distributed systems since it has built-in support for cross-cutting concerns, and it offers a suite of APIs for communication, state and workflow, that make developers more efficient. According to the State of Dapr Report, 95% of Dapr developers claim that Dapr saves time, and 55% of the developers surveyed claimed it saved them more than 30% of development time.

The usage of Dapr is also increasing thanks to a growing number of platforms that support the Dapr APIs. Dapr is no longer limited to running as a sidecar in Kubernetes, as is described in Dapr Deployment Models. In this article, Diagrid Catalyst, a suite of serverless Dapr APIs, is used to orchestrate services with Dapr workflow, and interact with message brokers and key-value stores.

Throughout this article, you’ll be using the following to configure a distributed system:

Two Dapr services (.NET)
Two serverless functions (JavaScript)
A front-end (Vue)
A key value state store
A pub/sub message broker
Diagrid Catalyst as the serverless API layer to connect everything

TLDR: Check the code on GitHub and join the Catalyst early access program.

Diagrid Pizza Store

The demo that is used in this article revolves around an online pizza store, where the user selects pizzas, orders them, and follows the progress of the order in realtime. It’s a simplified example where the durable workflow focuses on the inventory of ingredients, and communicating with the kitchen. The source code is on GitHub.

Architecture

The solution includes:

Two Dapr web services written in .NET, PizzaOrderService and KitchenService. In this demo, they’re running locally, but these can be hosted in any cloud that supports ASP.NET services.
The website (based on Vue) and two serverless functions written in JavaScript, getAblyToken and placeOrder. These are hosted on Vercel.
Ably as the realtime communication component between the PizzaOrderService and the website.
A key/value store to manage inventory (managed by Diagrid).
A pub/sub message broker to communicate between the PizzaOrderService and the KitchenService (managed by Diagrid).
Diagrid Catalyst that offers serverless APIs for communication, state, and workflow powered by Dapr.

Workflow

The PizzaOrderService contains a Dapr workflow that orchestrates the activities for checking the inventory and communicating with the KitchenService.

The workflow also contains activities for sending realtime messages to the website, these have been omitted from the workflow diagram to keep it concise.

Running the Pizza Store locally

Prerequisites

The following services, tools, and frameworks are required for this demo:

Diagrid Catalyst account (sign up for early access) and the Diagrid CLI
Vercel account (hobby) and the Vercel CLI
Ably account (free)
.NET 8 SDK
Node 18

All the code for the website, serverless functions, and back-end services is available in the catalyst-pizza-demo GitHub repository. This repository contains a devcontainer configuration that has the following preinstalled: .NET 8, Node LTS, Vercel CLI, Diagrid CLI.

You can use this devcontainer locally in VSCode (requires Docker Desktop) or directly in GitHub Codespaces. The npm install and dotnet build commands described in this article can be skipped if the devcontainer is used.

GitHub

Fork the catalyst-pizza-demo and clone it locally, or use GitHub Codespaces (recommended).

Ably

Ably is used as the serverless realtime messaging component. There is a default Ably app when you sign up for an account that can be used for this demo. Alternatively, you can create a new Ably app.

Log into the Ably portal.
Using the Ably portal: copy the Root API key from the Ably app. This will be copied later as an environment variable for both Vercel and Diagrid.

Vercel

The Vue-based front-end and two JavaScript functions are hosted on Vercel. The Vercel CLI is used to configure and run these resources locally.

Open a terminal in the root of the repository and login with the Vercel CLI:
```
vercel login
```
Go to the front-end folder and run:
```
npm install
```
Go back to the root of the repository and set up the Vercel project by running:
```
vercel
```
Follow the CLI prompts, and select the following options:
- Setup and deploy: Y
- Scope: <account name>
- Link to existing project: N
- What's your project's name? catalyst-pizza-project
- In which directory is your code located? ./front-end
- Want to modify these settings? [y/N] n
- Wait for the deployment to complete.
An environment variable is used in the getAblyToken function to generate a token for the website to communicate with the Ably realtime service. Add the Ably API token variable by running vercel env add:
- Variable name: ABLY_API_KEY
- Variable value: Use the Ably API key obtained from the Ably portal earlier
- Select Development as the environment.
Another environment variable is used in the placeOrder function to send a request to the PizzaOrderService that will start the workflow. Add the WORKFLOW_URL variable by running vercel env add:
- Variable name: WORKFLOW_URL
- Variable value: http://localhost:5064/workflow/orderReceived
- Select Development as the environment.
Run vercel pull to pull the configuration from Vercel to your local environment.
Run vercel build to build the website and the serverless functions to ensure there are no errors.

Diagrid Catalyst

Diagrid Catalyst provides serverless Dapr APIs that enables developers to quickly build distributed applications with workflow, pub/sub messaging, service invocation, and state management capabilities. Diagrid also provides managed infrastructure for storing data in a key/value store, pub/sub messaging, and workflow, which are all used in this solution.

The Diagrid CLI is used to configure the resources and run the .NET services locally.

Open another terminal in the root of the repository and use the Diagrid CLI to log in to Diagrid:
```
diagrid login
```
Create a new Catalyst project named catalyst-pizza-project and use the Diagrid managed pub/sub broker & KV store, and enable the managed workflow API:
```
diagrid project create catalyst-pizza-project --deploy-managed-pubsub --deploy-managed-kv --enable-managed-workflow --wait
```
To set this project as the default in the CLI run:
```
diagrid project use catalyst-pizza-project
```
Create a new App ID for the PizzaOrderService:
```
diagrid appid create pizzaorderservice
```
Create a new App ID for the KitchenService:
```
diagrid appid create kitchenservice
```
Before continuing, check the App ID status to make sure they are ready:
```
diagrid appid list
```

Create a pub/sub subscription for the KitchenService to receive messages from the PizzaOrderService:

diagrid subscription create pizzaorderssub --connection pubsub --topic pizza-orders --route /prepare --scopes kitchenservice

Create a pub/sub subscription for the PizzaOrderService to receive messages from the KitchenService:

diagrid subscription create preparedorderssub --connection pubsub --topic prepared-orders --route /workflow/orderPrepared --scopes pizzaorderservice

Verify that creation of the subscriptions is completed:
```
diagrid subscription list
```

Run diagrid dev scaffold to create a new local dev environment file. This creates a yaml file, named dev-.yaml with the following content:

project: catalyst-pizza-project
apps:
- appId: kitchenservice
appPort: 0
env:
    DAPR_API_TOKEN: diagrid://<dapr_api_token>
    DAPR_APP_ID: kitchenservice
    DAPR_GRPC_ENDPOINT: https://<grpc_endpoint>
    DAPR_HTTP_ENDPOINT: https://<http_endpoint>
workDir: kitchenservice
command: []
- appId: pizzaorderservice
appPort: 0
env:
    DAPR_API_TOKEN: diagrid://<dapr_api_token>
    DAPR_APP_ID: pizzaorderservice
    DAPR_GRPC_ENDPOINT: https://<grpc_endpoint>
    DAPR_HTTP_ENDPOINT: https://<http_endpoint>
workDir: pizzaorderservice
command: []
appLogDestination: ""

This file is gitignored since it contains secrets from Diagrid Catalyst. The appPort, command, and workDir attributes still need to be updated as follows:

Update the appPort for the kitchenservice to 5066.
Update the appPort for the pizzaorderservice to 5064.
Update the command arguments to ["dotnet", "run"] for both apps.
Update the workDir argument to point to back-end/KitchenService and back-end/PizzaOrderService respectively.
Update the appLogDestination to console.
Add an ABLY_API_KEY environment variable for the pizzaorderservice appId and set the value to the Ably API key obtained from the Ably portal.
Save the changes to the file.

Update the key/value store to allow shared state

The two .NET services share the same state in the key/value store to manage inventory and orders. Since this is not the default usage of state stores and services when using Dapr, an attribute needs to be set to enable this. The default behavior is that a key is prefixed with the app ID of the service that is using it. In this case, however, the keyPrefix is set to name to make sure both services use the same keys.

Run the following command to update the managed key/value store:
```
diagrid connection apply -f ./infra/kv.yml
```
This will upload the kv.yml file to Diagrid and update the configuration of the kvstore connection so keyPrefix is set to name.

Inspect the DaprClient configuration

The two .NET services use the Dapr .NET client SDK for workflow, state management and pub/sub messaging. The DaprClient is configured to use the endpoints provided by Diagrid Catalyst in the Program.cs file:

var apiToken = Environment.GetEnvironmentVariable("DAPR_API_TOKEN");
var grpcEndpoint = Environment.GetEnvironmentVariable("DAPR_GRPC_ENDPOINT");
var httpEndpoint = Environment.GetEnvironmentVariable("DAPR_HTTP_ENDPOINT");

builder.Services.AddDaprClient(options => {
    options.UseDaprApiToken(apiToken);
    options.UseGrpcEndpoint(grpcEndpoint);
    options.UseHttpEndpoint(httpEndpoint);
});

To use service invocation with the HTTP API, the HttpClient is configured with the DAPR_APP_ID and DAPR_API_TOKEN environment variables:

var appId = Environment.GetEnvironmentVariable("DAPR_APP_ID");
var apiToken = Environment.GetEnvironmentVariable("DAPR_API_TOKEN");

builder.Services.AddHttpClient(
    "daprEndpoint",
    client => {
        client.BaseAddress = new Uri(httpEndpoint);
        client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Add("dapr-app-id", appId);
        client.DefaultRequestHeaders.Add("dapr-api-token", apiToken);
    });

Running & testing the solution

Open a terminal in the root of the repository.

To restore and build the .NET projects run:

dotnet build ./back-end/PizzaOrderService
dotnet build ./back-end/KitchenService

Run diagrid dev start to start the PizzaOrderService and the KitchenService.
Using another terminal in the root of the repository, run vercel dev to start the website and the serverless functions locally.
Navigate to the URL provided by the Vercel CLI to view the website.
Select some pizzas, place an order, and watch the progress of the workflow in realtime.

Using the Catalyst API explorer

You can use the API explorer in the Catalyst web UI to interact with the APIs. If you want to retrieve the order item from the key/value store that has just been processed, follow these steps:

Open the developer tools console of the browser that is running the demo (a pizza order must be started or completed).
The order is logged to the console as a JSON object. Copy the OrderId property value.
Navigate to the Catalyst web UI. Ensure you're in the catalyst-pizza-project project.
Select App IDs in and click on the API explorer tab.
- Select the State API.
- Select the pizzaorderservice as the app ID.
- Select GET as the API operation.
- Select kvstore as the state connection.
- Enter Order- as the key, where is substituted with the value copied from the developer tools console.
Click Send. The response should show the state of the order item.

What’s next?

Congratulations! You’ve now used the Diagrid Catalyst serverless Dapr APIs for workflow, pub/sub messaging, service invocation, and state management. The ability to use these APIs from anywhere, without the overhead of managing Kubernetes clusters, brings great flexibility to developers on any platform to build distributed applications. The Dapr applications used in this demo can be hosted on any cloud. The demo uses the Diagrid managed infrastructure for key/value storage and pub/sub messaging, but these can be swapped out for other cloud-based resources, similarly to switching open-source Dapr components. You can extend this demo with an alternative pub/sub broker or state store by configuring other infrastructure connections.

Any questions or comments about this demo? Join the Dapr Discord and drop us a message in the #diagrid channel!

Dapr v1.11 Release Highlights

Marc Duiker — Mon, 19 Jun 2023 12:27:24 +0000

The Dapr maintainers released a new version of Dapr, the distributed application runtime, last week. This post highlights the major new features and changes for the APIs and components in release 1.11.

APIs

Dapr provides a common set of APIs for building microservices quickly and reliably. The new building block APIs, and major upgrades to existing APIs, are described in this section.

Configuration API stable

The Configuration building block allows developers to easily consume application configuration values as key/value pairs. Use this API to retrieve values that are likely to change over time but are coupled to the service. For instance, this API can be used to get App IDs, which are used when invoking other Dapr services. Or to get a component name of a state store when using the State Management API.

Applications can subscribe to changes of these configuration values, so the apps always use the latest value. The Configuration API was introduced in Dapr v1.5, and it’s great to see it now stable in v1.11.

Get a configuration value

GET http://localhost:<daprPort>/v1.0/configuration/<storeName>?key=<keyName>

Subscribe to configuration changes

GET http://localhost:<daprPort>/v1.0/configuration/<storeName>/subscribe

Service Invocation for non-Dapr endpoints 🆕

An exciting new preview feature is the ability to invoke non-Dapr endpoints. This feature enables developers to apply resiliency policies, access control via scoping, header authentication, and middleware to any endpoint. This gives you nearly all the benefits of service invocation when calling any HTTP API. Invoking non-Dapr endpoints can also be very useful when working on existing code bases where Dapr can be introduced incrementally.

Non-Dapr endpoints can be invoked in two ways:

Using an HTTPEndpoint resource type.

GET http://localhost:<daprPort>/v1.0/invoke/<HTTPEndpoint-name>/method/<my-method>

The HTTPEndpoint resource is specified in a yaml file:

apiVersion: dapr.io/v1alpha1
kind: HTTPEndpoint
metadata:
  name: <NAME>  
spec:
  version: v1alpha1
  baseUrl: <REPLACE-WITH-BASEURL> # Required. Use "http://" or "https://" prefix.
  headers: # Optional
  - name: <REPLACE-WITH-A-HEADER-NAME>
    value: <REPLACE-WITH-A-HEADER-VALUE>
  - name: <REPLACE-WITH-A-HEADER-NAME>
    secretKeyRef:
      name: <REPLACE-WITH-SECRET-NAME>
      key: <REPLACE-WITH-SECRET-KEY>
scopes: # Optional
  - <REPLACE-WITH-SCOPED-APPIDS>
auth: # Optional
  secretStore: <REPLACE-WITH-SECRETSTORE>

Using the Fully Qualified Domain Name (FQDN) of the endpoint.

GET http://localhost:<daprPort>/v1.0/invoke/<FQDN_URL>/method/<my-method>

Workflow updates

The Dapr Workflow management API has been updated to allow workflows to be paused, resumed, and purged. Purging workflows means the workflow state will be deleted. Once a workflow has been completed, it’s a good practice to purge the workflow state to keep the storage requirements to a minimum. In addition, workflows can now wait for external events. This is particularly useful for business processes that involve human interaction, such as approval workflows, or waiting for callbacks from other long-running processes.

These are the current Workflow management HTTP API methods:

POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/start
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/terminate
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/pause
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/resume
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/purge
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/raiseEvent/<eventName>

Note that the Workflow management API, which is still in preview, has breaking changes compared to v1.10. The changes are outlined in this GitHub issue. Another breaking change is the ability to support multiple workflow apps in a single cluster, as mentioned in this GitHub issue.

The Dapr Python SDK has been upgraded to allow authoring of workflows, so now workflow applications can be written in either C# or Python.

Cryptography API 🆕

The Cryptography API is a new preview building block that enables developers to encrypt/decrypt data in a safe and consistent way. Cryptography can be used within key vaults or the Dapr sidecar without exposing cryptographic keys to the application. With this new API, a set of new Cryptography components is made available that is listed in the New Components section.

These examples show how data can be encrypted and decrypted with the Cryptography API using the Dapr JavaScript SDK:

Encryption

// When passing data (a buffer or string), `encrypt` returns a Buffer with the encrypted message
const ciphertext = await client.crypto.encrypt(plaintext, {
    // Name of the Dapr component (required)
    componentName: "mycryptocomponent",
    // Name of the key stored in the component (required)
    keyName: "mykey",
    // Algorithm used for wrapping the key, which must be supported by the key named above.
    // Options include: "RSA", "AES"
    keyWrapAlgorithm: "RSA",
});

Decryption

// When passing data as a buffer, `decrypt` returns a Buffer with the decrypted message
const plaintext = await client.crypto.decrypt(ciphertext, {
    // Only required option is the component name
    componentName: "mycryptocomponent",
});

For more info on how to use the Cryptography API, see the Dapr docs.

Components

Dapr decouples the functionality of the common set of APIs with their underlying implementations via components. Components of the same type are interchangeable since they implement the same interface. Release 1.11 contains both new components as improvements to existing components.

New components

Bindings

WASM: allows invoking applications compiled to WebAssembly and run in modern browsers.
Kitex: allows invoking Generic Calls in Kitex, a high-performance and strong-extensibility Golang RPC framework.

State Stores

etcd: enables state store functionality using etcd, a distributed, reliable key-value store.

Cryptography

Azure Key Vault: enables cryptography functionality using Azure Key Vault.
Local storage: enables cryptography functionality using local files. Supported file formats are PEM, JSON Web Key, and raw key data for symmetric keys.
JWKS: enables cryptography functionality using JSON Web Key Sets (JWKS).
Kubernetes Secrets: enables cryptography functionality using Kubernetes secrets.

Component improvements

With 1.11 many components have graduated to the Stable certification level, which means these can be used in production confidently. All components have a certification level as mentioned in the Certification Lifecycle. The Stable level means:

The component must have component certification tests validating functionality and resiliency.
The component is maintained by Dapr maintainers and supported by the community.
The component is well documented and tested.
The component has been available as Alpha or Beta for at least 1 minor version release of Dapr runtime prior.
A maintainer will address component security, core functionality and test issues according to the Dapr support policy and issue a patch release that includes the patched stable component.

The following components have progressed to Stable:

Bindings

AWS S3: output binding to store data in AWS S3 buckets.

Middleware

Rate limit: restricts the maximum allowed HTTP requests per second.
OpenID Connect: verifies a bearer token using OpenID Connect.

Pub/Sub

GCP Pub/Sub: enables pub/sub messaging using Google Cloud Platform Pub/Sub.

State stores

GCP Firestore: enables state store functionality using Google Cloud Platform Firestore.
SQLite: enables state store functionality using SQLite 3.

Configuration stores

PostgreSQL: enables configuration store functionality using PostgreSQL.
Redis: enables configuration store functionality using Redis.

If you're using any of these components and have a demo to show, drop a link in the #show-and-tell channel on the Dapr Discord.

*Azure components authentication improvements*

Azure AD authentication has been added to the Azure Storage Queues binding and the SQL Server state store.

All Azure components that support Azure AD now support authentication using:

Azure AD Workload Identity on Kubernetes
Azure CLI credentials.

What is next?

This post is not a complete list of features and changes released in version 1.11. Read the official Dapr release notes for more information. The release notes also contain information on how to upgrade to this latest version.

Excited about these features and want to learn more? I'll cover the new features in more detail in future posts. Until then, join the Dapr Discord to connect with thousands of Dapr users.

Creating a Dapr pluggable component for Supabase

Marc Duiker — Tue, 25 Apr 2023 14:56:41 +0000

In this post, you’ll learn how to use the Dapr pluggable component .NET SDK and the Supabase C# library to build a pluggable state store component that uses Supabase tables.

If you prefer watching a video instead of reading this blog post, head over to YouTube and watch this:

Dapr, the open-source, portable, event-driven runtime for building distributed applications, comes with over 100 built-in components which can be used to integrate resources across many clouds or on-premise systems. If those components are not enough, or you want to create something custom for your specific needs, you can create a pluggable component. The Dapr building block APIs that are pluggable are:

State management
Publish and subscribe
Input and output bindings

Since Dapr release 1.10 there are pluggable component SDKs available that make it easier to create them.

Supabase is a popular, open-source, Firebase alternative that offers Postgres databases, authentication, Edge functions, real-time messaging and file storage. The Supabase community has released a C#/.NET library that developers can use to integrate their .NET apps with the Supabase platform. For managing Postgres databases, the library uses the postgrest-csharp library that allows developers to use strongly typed models and LINQ queries.

This post describes the steps required to make a proof of concept Dapr pluggable component using .NET 7 that combines both the Dapr pluggable component .NET SDK and the Supabase C# library. The result is an ASP.NET application, that is run locally, and tested by making HTTP requests to interact with the state stored in a Supabase table.

1. Prerequisites

.NET 7 SDK
Dapr CLI
A Supabase account, you can sign up for free.
Supported OS: macOS, Linux, WSL on Windows.

2. Creating the DaprPluggableSupabase .NET project

If you’re more interested in using the pluggable component instead of creating it from scratch, continue with section 3. Supabase Setup.

Clone this repo, open a terminal and navigate to the src folder.

The cloned repository already contains an ASP.NET app in the DaprPluggableSupabase folder that is the pluggable component. You can use this as a reference.
Create a new .NET web project, and make sure to use a different name than DaprPluggableSupabase (e.g. MyDaprPluggableSupabase):

dotnet new web --name MyDaprPluggableSupabase
Change to the MyDaprPluggableSupabase folder and add the Dapr.PluggableComponents.AspNetCore and supabase-csharp NuGet packages:

cd MyDaprPluggableSupabase

dotnet add package Dapr.PluggableComponents.AspNetCore

dotnet add package supabase-csharp
Create a new class file in the MyDaprPluggableSupabase folder named KeyValue.cs.
Add the following content to this new class:

using Postgrest.Attributes;
using Postgrest.Models;

namespace DaprPluggableSupabase
{
    [Table("dapr_state_store")]
    public class KeyValue : BaseModel
    {
        [PrimaryKey("id")]
        public int Id { get; set; }

        [Column("created_at")]
        public DateTime CreatedAt { get; set; }

        [Column("key")]
        public string? Key { get; set; }

        [Column("value")]
        public string? Value { get; set; }
    }
}

The KeyValue class defines the data type that will be stored in the Supabase table. It inherits from BaseModel, which is part of the Supabase postgrest-csharp library. This library uses attributes that can be used to decorate the class and properties, which makes it easier for developers to use strongly typed models when interacting with the database table. Dapr state stores are key/value stores and Postgres databases are object-relational data stores. Since this is not a perfect match, the Dapr key/value-based state management API is mapped to this KeyValue model to fit the Postgres schema.

Create a new class file in the MyDaprPluggableSupabase folder named SupabaseStateStore.cs.
Add the following content to this new class:

using System.Text;
using Dapr.PluggableComponents.Components;
using Dapr.PluggableComponents.Components.StateStore;

namespace DaprPluggableSupabase
{
    internal sealed class SupabaseStateStore : IStateStore
    {
#nullable disable
        private Supabase.Client _supabaseClient;
#nullable enable

        private const string PROJECT_APIKEY_KEYWORD = "projectApiKey";
        private const string PROJECT_URL_KEYWORD = "projectUrl";

        public async Task DeleteAsync(StateStoreDeleteRequest request, CancellationToken cancellationToken = default)
        {
            await _supabaseClient.From<KeyValue>()
                .Where(x => x.Key == request.Key)
                .Delete(cancellationToken: cancellationToken);
        }

        public async Task<StateStoreGetResponse?> GetAsync(StateStoreGetRequest request, CancellationToken cancellationToken = default)
        {
            KeyValue? kv = await GetKV(request.Key, cancellationToken);

            if (kv != null && kv.Value != null)
            {
                var valueAsBytes = Encoding.UTF8.GetBytes(kv.Value);
                var response = new StateStoreGetResponse() { Data = valueAsBytes };
                return response;
            }

            return new StateStoreGetResponse();
        }

        public async Task InitAsync(MetadataRequest request, CancellationToken cancellationToken = default)
        {
            if (!request.Properties.TryGetValue(PROJECT_URL_KEYWORD, out string? projectUrl))
            {
                throw new InvalidOperationException($"Missing required property \"{PROJECT_URL_KEYWORD}\" in component file.");
            }

            if (!request.Properties.TryGetValue(PROJECT_APIKEY_KEYWORD, out string? projectApiKey))
            {
                throw new InvalidOperationException($"Missing required property \"{PROJECT_APIKEY_KEYWORD}\" in component file.");
            }

            _supabaseClient = new Supabase.Client(projectUrl, projectApiKey);
            await _supabaseClient.InitializeAsync();
        }

        public async Task SetAsync(StateStoreSetRequest request, CancellationToken cancellationToken = default)
        {
            var newKV = new KeyValue
            {
                Key = request.Key,
                CreatedAt = DateTime.UtcNow,
                Value = Encoding.UTF8.GetString(request.Value.Span)
            };

            KeyValue? existingKV = await GetKV(request.Key, cancellationToken);

            if (existingKV != null)
            {
                newKV.Id = existingKV.Id;
                await _supabaseClient.From<KeyValue>().Update(newKV, cancellationToken: cancellationToken);
                return;
            }
            else
            {
                await _supabaseClient.From<KeyValue>().Insert(newKV, cancellationToken: cancellationToken);
            }
        }

        private async Task<KeyValue?> GetKV(string key, CancellationToken cancellationToken)
        {
            return await _supabaseClient.From<KeyValue>()
#nullable disable
                            .Select(x => new object[] { x.Id, x.Key, x.Value })
#nullable enable
                            .Where(x => x.Key == key)
                            .Single(cancellationToken);
        }
    }
}

Notice that the class inherits from IStateStore, this is the interface that all Dapr state store components implement. The interface contains three methods that require implementing:

DeleteAsync, this will delete a value from the store.
GetAsync, this will retrieve a value from the store.
SetAsync, this will insert/update a value to the store.

All methods use the Supabase C# client to manage the data via the KeyValue model.

The IStateStore interface inherits the IPluggableComponent interface that contains only one method, InitAsync, and this method used to initialize the state store. In this case, it is used to create an instance of the Supabase.Client.

Update the existing Program.cs file with the following content:

using Dapr.PluggableComponents;
using DaprPluggableSupabase;

var builder = WebApplication.CreateBuilder(args);
var app = DaprPluggableComponentsApplication.Create();

app.RegisterService(
    "supabase",
    serviceBuilder =>
    {
        serviceBuilder.RegisterStateStore<SupabaseStateStore>();
    });

app.Run();

This class defines the application as a DaprPluggableComponentApplication and registers the SupabaseStateStore as a new state store that will communicate with Dapr applications via a Unix domain socket named supabase.

Build the application to make sure there are no compilation errors:

dotnet build

3. Supabase Setup

The pluggable component will interact with a Supabase Postgres table. This section describes how to create the table using the Supabase dashboard and where to find the project URL and API key required in the next section.

Create a new database table with the following specifications:

Name: dapr_state_store
Primary Key: id, (int8, not null)
Columns:
- created_at (timestamptz, not null)
- key (text, not null)
- value (text, null)
RLS (Row Level Security) is disabled

Note that for production use, Row Level Security (RLS) should be enabled, and access policies should be added to the table.

Table definition:

create table
        public.dapr_state_store (
            id bigint generated by default as identity not null,
            created_at timestamp with time zone not null default now(),
            key text not null,
            value text null,
            constraint dapr_state_store_pkey primary key (id),
            constraint dapr_state_store_id_key unique (id)
        ) tablespace pg_default;

You'll need the Supabase project URL and public API key to configure the Dapr component file in the next section. This information is found in the Supabase dashboard in the project Settings > API tab.

4. Update the Dapr pluggable Supabase component file

Dapr uses a modular design where functionality is delivered as a component. A component file contains the specification of a component, including the name, the component type, and related metadata that is specific to connecting with the underlying resource. The component file for the Supabase state store looks like this:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pluggable-supabase
spec:
  type: state.supabase
  version: v1
  metadata:
  - name: projectUrl
    value: ""
  - name: projectApiKey
    value: ""

The value of the spec.type field, state.supabase, consists of two parts: the component type (state), and the socket name (supabase). The socket name needs to match with the socket name argument provided in the RegisterService method in the Program.cs class of section 2. A template of this component file is available in the repository, follow these steps to update the file, so it can be used locally.

Navigate to the resources folder in this repository.
Rename the resources\pluggableSupabase.yml.template file to resources\pluggableSupabase.yml.

The pluggableSupabase.yml file is added to .gitignore, so it won't be accidentally committed to source control for this demo app. For production use, the yaml files should be checked into source control and secret store references should be used, instead of plain text values.
Open the pluggableSupabase.yml file and update the values for projectUrl and projectApiKey obtained in the previous section.
Save the file and copy it to the user's Dapr components folder: ~/.dapr/components.

When the Dapr CLI is run, all the component files in this folder will be loaded, so the pluggable Supabase component should be available.

5. Run the DaprPluggableSupabase application

Regular Dapr components are part of the Dapr runtime and don't require additional processes to run. Pluggable components, however, are not part of the Dapr runtime and need to be run separately, which is done in this section.

The DaprPluggableSupabase project in this repo implements the Dapr state store interface and uses the Supabase C# library to access a Supabase table.

Open a terminal and navigate to the
1. src/DaprPluggableSupabase folder to use the included pluggable component project or
2. src/MyDaprPluggableSupabase folder to use the pluggable component project you’ve just created yourself.
Build the project:

dotnet build
Run the project:

dotnet run

6. Run the Dapr process and test the Supabase state store

Open a new terminal and use the Dapr CLI to run the Dapr process

dapr run --app-id myapp --dapr-http-port 3500

Expected output:

The output should contain an INFO message that the pluggable-supabase component is loaded:

INFO[0000] component loaded. name: pluggable-supabase, type: state.supabase/v1

The log should end with:

ℹ️ Dapr sidecar is up and running. ✅ You're up and running! Dapr logs will appear here.
Set a new state by making a POST request to the state management endpoint:

curl --request POST --url http://localhost:3500/v1.0/state/pluggable-supabase --header 'content-type: application/json' --data '[{"key": "key1","value": "This is stored in Supabase!"}]'

Expected output:

HTTP 204 No Content
Retrieve the new state using a GET request:

curl --request GET --url http://localhost:3500/v1.0/state/pluggable-supabase/key1

Expected output:

HTTP 200 OK

"This is stored in Supabase!"

Or have a look at the Supabase dashboard to see the new state record in the table.

You've now successfully created and used the Dapr pluggable Supabase state store component. 🎉

Next steps

This proof of concept implementation of a pluggable component demonstrates how the Dapr pluggable component .NET SDK makes it easier for developers to create their custom components. You can use this solution as a starting point, and expand it with additional state management API features, such as entity tag (ETag), metadata, and options, as described in the specification. A requirement for using this pluggable component in a real project is to deploy it to a (managed) Kubernetes environment or use it in a self-hosted mode.

The Supabase platform offers a great variety of useful back-end features, and with the set of client libraries it’s very accessible to a diverse group of developers. Take a look at Supabase Launch Week to read about their latest feature announcements.

From my perspective, I’d like to explore further how Dapr can integrate with other Supabase features. It would also be great to see a Supabase state store as a built-in component that’s available in the Dapr runtime without the need of running the pluggable component separately. I also hope the proposed DocumentStore building block will get some traction this year, since this will pair up very nicely with Supabase and other PostgreSQL stores.

Do you have any questions or comments about this blog post or the code? Join the Dapr discord and post a message in the #pluggable-components channel. Have you made something with Dapr? Post a message in the #show-and-tell channel, we love to see your creations!

Create event-driven applications with Cloudflare queues and Dapr

Marc Duiker — Thu, 09 Mar 2023 14:20:59 +0000

In this post, you’ll learn how to build a cloud to edge event-driven application with Dapr and Cloudflare. You’ll learn how to create:

A Cloudflare queue.
A consumer Cloudflare worker (in TypeScript) that reads messages from the queue.
A producer Dapr app (in TypeScript) that uses the Cloudflare Queue binding to publish messages to the queue.

Event-driven applications FTW 🚀

Event-driven applications are becoming increasingly popular. The decoupling of event producers and event consumers makes applications more resilient and flexible, since they allow independent implementation and scaling of the applications.

Cloudflare recently announced Queues, allowing developers to send and receive messages with guaranteed delivery and integrating with Cloudflare Workers, a fast edge computing platform.

Dapr, the open-source distributed application runtime, is often used in event-driven applications. Dapr provides a set of standardized API building blocks that simplify microservice development. By using the Bindings building block, developers can use input, and output bindings, and either trigger their apps or invoke other resources without having to learn resource-specific SDKs for these resources. With Dapr release 1.10, a new binding is provided that allows developers to publish messages to Cloudflare Queues. Because of the common set of APIs that Dapr offers, developers from any background can use the binding to publish messages to Cloudflare Queues without needing to know the Cloudflare SDKs or adding that dependency to their codebase.

Let’s start building an event-driven app and see the binding in action.

Prerequisites

The following is required to run this sample:

Clone this repository to your local machine.
Install Dapr CLI.
- Use the Dapr CLI to install the Dapr runtime locally:
  
  dapr init
Install Node.js.
Install Cloudflare Wrangler.
Ensure you're on a Cloudflare paid plan, since that is required to use Cloudflare queues.
Enable Queues in the Cloudflare dashboard.
- Dashboard > Workers > Queues
- Enable Queues Beta
- You should see a confirmation in the dashboard that queues are enabled.

Create the applications

The solution consists of three parts:

A Cloudflare queue
A consumer Cloudflare worker that reads messages from the queue.
A producer Dapr app that will publish messages to the queue.

1. Create a Cloudflare queue

Open a terminal and use the wrangler CLI to login to Cloudflare:

wrangler login

Follow the instructions in the browser to login to Cloudflare.

The response in the terminal should end with:

Successfully logged in.
Create the Cloudflare queue using the wrangler CLI:

wrangler queues create dapr-messages

The response in the terminal should end with:

Created queue dapr-messages.

2. Create a consumer Cloudflare worker

You can either create a new consumer worker by following steps 1-3, or use the existing consumer worker in this repository and continue from step 4.

In the root folder, create a worker to consume messages:

wrangler init consumer
1. Create package.json: Y
2. Use TypeScript: Y
3. Create worker: Fetch handler
4. Write tests: N
A new folder named consumer will be created which contains the worker.

Update the consumer/src/index.ts file to:

export default {
  async queue(
      batch: MessageBatch<Error>,
      env: Env
  ): Promise<void> {
      let messages = JSON.stringify(batch.messages);
      console.log(messages);
  },
};

Add the following lines to the consumer/wrangler.toml file:

[[queues.consumers]]
queue = "dapr-messages"
max_batch_size = 1

Ensure that you're in the consumer folder and install the dependencies:

cd consumer

npm install

Publish the consumer worker:

wrangler publish

The response in the terminal should end with:

Published consumer (... sec)
  https://consumer.<SUBDOMAIN>.workers.dev
  Consumer for dapr-messages
Current Deployment ID: <DEPLOYMENT_ID>

Start a tail to read the log of the consumer worker:

wrangler tail

3. Configure the producer Dapr app

The Cloudflare Dapr binding uses a Cloudflare worker to publish messages, since only Cloudflare workers can access the queue.

There are two options for this worker:

Dapr provisions the worker.
You use a pre-provisioned Cloudflare worker.

This sample uses option 1. Read the Cloudflare Queues binding spec and choose Manually provision the Worker script if you want to go for option 2.

Create a binding file

Rename the producer/resources/binding.yaml.template to producer/resources/binding.yaml.

Open the binding.yaml file and inspect its content.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: cloudflare-queues
spec:
  type: bindings.cloudflare.queues
  version: v1
# Increase the initTimeout if Dapr is managing the Worker for youinitTimeout: "120s"
  metadata:
# Name of the existing Cloudflare Queue (required)- name: queueName
      value: "dapr-messages"
# Name of the Worker (required)- name: workerName
      value: "dapr-message-worker"
# PEM-encoded private Ed25519 key (required)- name: key
      value: |
        -----BEGIN PRIVATE KEY-----
        MC4CAQ...
        -----END PRIVATE KEY-----
# Cloudflare account ID (required to have Dapr manage the Worker)- name: cfAccountID
      value: ""
# API token for Cloudflare (required to have Dapr manage the Worker)- name: cfAPIToken
      value: ""
# URL of the Worker (required if the Worker has been pre-created outside of Dapr)- name: workerUrl
      value: ""

The metadata.name, spec.metadata.queueName and spec.metadata.workerName values have already been set. Ensure that the queueName matches the queue setting in the consumer worker wrangler.toml file.

Values for spec.metadata.key, spec.metadata.cfAccountID, and spec.metadata.cfAPIToken still need to be provided.

Follow these instructions in the Dapr docs to set the value for spec.metadata.key.
The Cloudflare account ID should go in the spec.metadata.cfAccountID field. You can find the account ID in the Cloudflare dashboard URL: https://dash.cloudflare.com/<ACCOUNT_ID>/workers/overview.
A Cloudflare API token should go in the spec.metadata.cfAPIToken field. It can be generated as follows:
1. In the Cloudflare dashboard, go to the Workers page.
2. Click the API tokens link
3. Click the Create token button
4. Click the Use template button for Edit Cloudflare Workers
5. Update the permissions to only contain:
  - Account | Worker Scripts | Edit
6. Update the Account Resources to only contain:
  - Include | <YOUR ACCOUNT>
7. Set a time to live (TTL) for the token, the shorter, the better, if you're just testing.

Now the binding file is complete. The file is gitignored, so the secrets won't be committed to the repository.

Inspect the Node app

Let's have a look at the Dapr app that will send messages to the Cloudflare queue.

Inspect the producer/index.ts file.

import { DaprClient } from "@dapr/dapr";

// Common settingsconst daprHost = "http://localhost";
const daprPort = process.env.DAPR_HTTP_PORT || "3500";

async function main() {
    console.log("Starting...");

    const bindingName = "cloudflare-queues";
    const bindingOperation = "publish";
    const client = new DaprClient(daprHost, daprPort);
    for(var i = 1; i <= 10; i++) {
        const message =  { data: "Hello World " + i };
        const response = await client.binding.send(bindingName, bindingOperation, message);
        if (response)
        {
            console.log(response);
        }
        await sleep(1000);
    }

    console.log("Completed.");
}

async function sleep(ms: number) {
    return new Promise(resolve => setTimeout(resolve, ms));
  }

main().catch((e) => {
    console.error(e);
    process.exit(1);
})

Note that the bindingName is set to cloudflare-queues and matches the value of the metadata.name in the binding.yaml. The bindingOperation is set to publish (create could be used as an alias).

Run the producer app

Open a new terminal window and navigate to the producer folder.
Install the dependencies:
```
npm install
```

Run the following command to start the producer app:

dapr run --app-id producer --resources-path ./resources -- npm run start

The terminal that logs the tail of the consumer app should show a log statement for each of the ten messages sent:

Unknown Event - Ok @ 17/02/2023, 11:22:50
  (log) [{"body":"{\"data\":\"Hello World 1\"}","timestamp":"2023-02-17T10:22:50.556Z","id":"8f6293d9d04001e3f2a12be5c47acde2"}]
...

Congratulations! You’ve now sent messages from a Dapr app to a Cloudflare Queue (& Worker) via the Cloudflare Queues binding! 🎉 Hungry for more Dapr bindings? Have a look at the long list of supported bindings.

Any questions or comments about this blog post or the code? Join the Dapr discord and post a message in the #components-contrib channel. Have you made something with Cloudflare and Dapr? Post a message in the #show-and-tell channel, we love to see your creations!

How to upgrade your local Dapr runtime and CLI

Marc Duiker — Wed, 22 Feb 2023 08:51:26 +0000

EDIT: updated for the Dapr 1.15 release :)

I've recently upgraded my local Dapr runtime and the Dapr CLI due to the new 1.15 release being available. Since I'll be upgrading to new releases on a regular basis, and use both Mac and a Windows machines, I might as well help my future self and write this down since I forget these things after a week 😅.

Upgrading the self-hosted environment (which I call the runtime) is described in detail in the official docs, but here I'm writing a slimmed down version, useful if you're either running Windows with winget, or macOS with Homebrew.

Uninstall the old Dapr runtime:
```
dapr uninstall
```
If you also want to remove the Redis and Zipkin images run:
```
dapr uninstall --all
```
Install the new Dapr runtime:
```
dapr init
```
Upgrade the Dapr CLI:

Using Windows and winget:
```
winget upgrade Dapr.CLI
```
Using macOS and brew:
```
brew upgrade dapr-cli
```
Verify that everything is upgraded:
```
dapr -v
```
The response should list the new versions:
```
CLI version: 1.15.0
Runtime version: 1.15.2
```
`

🚨 Bleeding edge 🚨

If you need the very latest, (bleeding) edge bits of Dapr, you can:

Pull the runtime images from the Dapr GitHub container registry.
Download the Dapr CLI release candidates from the Dapr CLI GitHub release page.

Enjoy the latest Dapr release!