In this Cloudflare TV segment, developer advocate Marc Duiker joins Gift Egwuenu to show how the Distributed Application Runtime (Dapr) streamlines building event-driven, distributed applications—and how you can run those same Dapr-powered workloads at the edge using Cloudflare Queues and Workers.
Watch the video on Cloudflare TV ↗
Why Dapr?
Modern systems are a web of microservices—payments, email, cart, checkout—communicating asynchronously. That power comes with cross-cutting headaches: service-to-service calls, retries, tracing, state, secrets, and more. Dapr tackles those concerns with portable, building-block APIs you call from any language (HTTP/gRPC or client SDKs like JavaScript):
- Service invocation
- State management (e.g., swap Redis ↔ Cloudflare KV via config)
- Pub/Sub
- Input/Output bindings
- Actors
- Secrets & configuration
- Observability
- Patterns like distributed locks & long-running workflows
Dapr runs as a sidecar alongside your app—on Kubernetes, VMs, or edge environments—so your code calls consistent Dapr APIs while a component abstraction maps those calls to the underlying platform you choose.
Key Takeaways from the Webcast
1) Clean separation via components (YAML, not code)
Your application references a component name; Dapr’s YAML maps that to a concrete backend. Example shown: a state component targeting Cloudflare KV (state.cloudflare.workers.kv). Swapping KV for Redis is a config change—not a code change—so local dev and cloud/edge deploys stay in sync.
2) Event publishing with a Dapr binding for Cloudflare Queues
The demo app uses an output binding to publish messages. Under the hood, only a Cloudflare Worker can talk to Queues, so Dapr can provision that Worker for you (or you can provide your own). Your app simply calls the Dapr binding (operation: publish) and remains platform-agnostic.
3) Secure, production-ready setup
Secrets (API tokens, keys, account IDs) belong in your secret store—not in source control. The transcript highlights:
- Using a Cloudflare API token with the minimal account.worker.scripts permission.
- Keeping sensitive values out of the public YAML template and injecting them for real runs.
4) Portable, polyglot developer experience
The demo is in JavaScript with the Dapr SDK, but any language works as long as it can speak HTTP/gRPC. Dapr is a CNCF incubating project with an active community and Discord for help.
What Mark's Demo Shows (End-to-End)
- Prereqs: Dapr CLI, Node.js, Wrangler; Queues enabled on a paid Cloudflare plan.
- Create a Queue (via Wrangler).
- Deploy a consumer Worker that logs incoming messages from the Queue.
- Configure Dapr binding (YAML) with the queue name, worker name, and credentials.
- Run the producer app locally with dapr run …—it loops and sends “hello world” messages through Dapr → Worker → Queue → Worker consumer.
- Observe delivery with wrangler tail to confirm messages land.
Why This Matters (from a Dapr point of view)
- Less glue code: Your business logic calls Dapr APIs; Dapr maps to Cloudflare services.
- Swap backends freely: Change YAML, not app code (e.g., Redis locally, KV in prod).
- Operational safety: Built-in patterns for retries, tracing, secrets, and workflows.
- Edge-ready: Keep the same Dapr app while running closer to users for latency wins.
Where to Go Next
- Dapr docs & spec for bindings and components
- Dapr Discord for help (bindings section; the Cloudflare binding maintainer hangs out there)
- The Diagrid Labs repo demonstrated in the webcast (producer + consumer example)
