How I learned Dapr building tweet sentiment processing pipeline
I recently joined the Office of CTO in Azure at Microsoft and wanted to ramp up on one of the open source projects the team has built there called Dapr. Dapr describes itself as:
A portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
I learn technology best by using it, so I decided to build a simple tweet sentiment processing pipeline and see how easy and portable it really is. The resulting project with source code, which you can run both locally and on Kubernetes, is available here.
A few takeaways from my experience:
- Dapr was easy to start with, thanks mainly to the very thorough documentation and its dead simple CLI. The local development experience in Dapr also felt natural. I was able to use my existing skills and get something going within 10–15 minutes.
- I did like that Dapr didn’t have any “invasive” libraries or required SDKs. There are client libraries in most languages, but its API is well structured and has feature parity in both HTTP and gRPC. I, actually, ended up writing my own HTTP client (godapr), just to get a better “feel” for the API.
- The opt-in abstractions for state and pub/sub enable easy portability. I used Redis for both during local development and then swapped for Azure Storage Table and Azure Service Bus when deploying to Kubernetes without any code changes.
- The growing list of bindings allow developers to quickly integrate backing services with minimal effort. Everything from generic ones like Kafka or MQTT to Cloud-provider specific ones like DynamoDB or S3 for AWS, Cloud Pub/Sub and GCS for GCP, or EventGrid and EventHubs for Azure. Building these extensions is pretty easy too. I contributed the Twitter input binding, which went out in the recent Dapr v0.7 release.
- When building apps based on multiple microservices like my pipeline, Dapr provides a consistent service discovery and invocation mechanism, whether locally or on Kubernetes.
Dapr seems to strike the right balance between helping developers with primitives, like persisting state or eventing though pub/sub, without being too overbearing.
I look forward to working on Dapr, contributing to the project, and yes, developing with on Dapr myself.
