In this “Exploring Dapr” series, I’m exploring some of its capabilities and sharing my thoughts on it.  Dapr is an event-driven portable runtime for building micro-services, for more information I refer to the documentation.  Be aware that Dapr is currently under constant evolution, so some of the described behavior or findings might not be accurate anymore in the future.

This blog post is based on Dapr version 0.3 and focuses on its publish / subscribe messaging capabilities.

The Dapr concept

This blog series is all about the pub/sub messaging concept, which is described over here.  It’s a common architecture pattern that allows to decouple message producers from its consumers.

The following features are covered:

• Publish a message to a topic
• Subscribe with multiple consumers on a topic, each gets its own message copy
• Per subscriber, multiple instances are supported (competing consumers)
• At-least-once reliability is guaranteed
• Support for Cloud Events 0.3

Some folks might be expecting the property-based message filtering capabilities that are often used within publish/subscribe patterns, but this is not covered by Dapr.

The Dapr API

The Dapr sidecar takes care of all the plumbing.  Your application code just needs to interact with the sidecar through HTTP (gRPC is also supported).  All details about the API are describe here.

• To publish a message, the application must perform a call to the sidecar:

POST http://localhost:<daprPort>/v1.0/publish/<topic>

• There is also the ability to broadcast a message to a list of recipients.
• Dapr needs to know to which topics it must subscribe.  Your application code must return an array of topics it wants to subscribe to, via this application endpoint:

GET http://localhost:<appPort>/dapr/subscribe

• The Dapr sidecar will listen on the configured topics and will send the payloads to the following application endpoint.  You have to listen to these incoming API calls:

POST http://localhost:<appPort>/<topic>

One limitation of this approach, is the fact that a single application can only subscribe once to a certain topic.  In some scenarios I have in mind, this would be an issue.  I filed an issue on the Dapr GitHub repo, curious on the feedback.

The Dapr components

At the time of writing, the following publish / subscribe implementations are available:

• Redis Streams
• NATS
• Azure Service Bus
• RabbitMQ
• Kafka

It was a little difficult to find the corresponding component descriptions inside the Dapr documentation, but here they are!

Conclusion

Pretty clean and simple implementation of the powerful publish / subscribe pattern.  This was a rather theoretical overview.  Time to get our hands dirty in the next parts of this blog series!

Cheers
Toon