Dapr v1.12 Release Highlights
This post highlights some of the major new features and improvements of Dapr, the Distributed Application Runtime, that provides APIs for communication, state, and workflows.
The Dapr maintainers released a new version of Dapr, the distributed application runtime, last week. Dapr provides APIs for communication, state, and workflow, to build secure and reliable microservices. This post highlights the major new features and changes for the APIs and components in release v1.12.
Dapr provides an integrated set of APIs for building microservices quickly and reliably. The new APIs, and major upgrades to existing APIs, are described in this section.
This transactional outbox pattern is added to the transactional state management API. This pattern allows committing a single transaction across a state store and a pub/sub message broker, and is ideal for sending notifications when changes occur in application state. The outbox pattern is compatible with all transactional Dapr state stores, and all pub/sub brokers that Dapr can use.
A typical use case for the outbox pattern is:
- Adding a new user account to a state store.
- Publishing a message that the account has been successfully added.
To configure the outbox pattern, the following fields need to be specified in the state management component file:
- <inline-h>outboxPublishPubsub<inline-h>; this is the name of the pub/sub component.
- <inline-h>outboxPublishTopic<inline-h>; this is the name of the pub/sub topic.
MySQL state store example with outbox pattern specification
To use the outbox pattern in your application, use the state management transaction API:
More information on outbox configuration, supported state stores, and usage of the transactional outbox pattern can be found in the docs.
Workflow now in beta
Dapr workflow enables developers to orchestrate business logic for messaging and state management across various microservices. The Dapr Workflow API has progressed to beta maturity level with release 1.12. This means that:
- It’s not production ready yet.
- Recommended for non-business-critical use.
- Development will continue until stable maturity level is reached.
- The API contract is close to finalization.
- Supports several Dapr language SDKs, in this case, .NET, Python, and Java.
- Performance should be production-ready, but may not be achieved in all cases.
Authoring Workflows in Java
Workflow authoring was already supported for .NET and Python. Now, Java can be used to author workflows as well. This requires a dependency on the io.dapr.workflow package that contains the necessary Workflow type definitions.
See the Dapr java-sdk GitHub repository for a full workflow demo.
Improvements to Dapr Actors and Placement APIs
Many improvements have been made to the Dapr Actors API, including bug fixes and performance improvements.
- The Placement service has a new placement API that allows examination of the placement tables to find out which types of actors are active.
- The response contains an array of actor host info:
- For more information, read the Placement API reference in the docs.
- API calls to Actor and Workflow endpoints are now blocking while the Dapr Actor runtime is initialized, so applications are do not need to implement this readiness check any longer.
- Performance improvements have been made to Actor Reminders to prevent multiple re-evaluations when multiple sidecars are online/offline at the same time.
Service Invocation: HTTP streaming
The HTTP service invocation API now uses streaming by default, which enhances the overall performance of HTTP service invocation, especially when using large request or response bodies.
Users who use HTTP service invocation will experience improvements such as reduced memory usage, much smaller time-to-first-byte (TTFB), and the ability to send messages in chunks.
More information about service invocation with HTTP streaming can be found in the docs.
Dapr decouples the functionality of the integrated set of APIs with their underlying implementations via components. Components of the same type are interchangeable since they implement the same interface. Release 1.12 contains both new components as improvements to existing components.
- <inline-h>completion<inline-h>; this generates responses on a prompt.
- <inline-h>chat-completion<inline-h>; this generates responses for a chat message.
- <inline-h>get-embedding<inline-h>; this returns a vector representation of the input that can be easily used by machine learning models.
The minimum component file configuration is as follows:
To use this binding, make a POST request to the <inline-h>/bindings/<binding-name> <inline-h> endpoint:
and provide a JSON payload:
For more information about this binding, please visit the docs.
Secret stores now supported as pluggable component
Secret stores have been added to the pluggable component model. This means you can now write custom secret store components and use these in your Dapr applications. Other pluggable component types are state stores, pub/sub and bindings. You can write pluggable components in Go or .NET.
The following components have been promoted to stable status:
- Pub/sub: Azure Service Bus Queues
- Binding: Zeebe command
- Binding: Zeebe jobworker
- In-memory pub/sub and In-memory state store components
- All transactional state stores now include TTL information when retrieving metadata. Metadata can be retrieved by making a GET request to the metadata endpoint:
In addition, the queue name can be set via subscription metadata.
All PostgreSQL components (binding, configuration store, state store) now support authentication with Azure AD.
Name resolution is used in service-to-service invocation when the name of a Dapr application needs to be resolved to the location of the corresponding Dapr sidecar. You can now override the default Kubernetes DNS name resolution by adding a Dapr configuration CRD that contains a nameResolution spec:
If you're using any of these components and have a demo to show, drop a message in the #show-and-tell channel on the Dapr Discord.
CLI & Multi App Run
Improvement to Kubernetes developer experience
A new CLI command has been added to improve setting up a dev environment on Kubernetes. Using <inline-h>dapr init -k --dev <inline-h> will deploy a Redis and Zipkin containers to Kubernetes identical to the (local) self-hosted mode. For more information on <inline-h>dapr init <inline-h>, please see the docs.
Specify multiple resource paths
Multiple resource paths can now be used when starting apps with <inline-h>dapr run<inline-h> to allow loading of multiple component/resource files across several locations.
See the Dapr docs, for all the flags available for <inline-h>dapr run<inline-h>.
Windows support for Multi-app Run
Multi-app run allows running multiple Dapr applications in (local) self-hosted mode, with just one CLI command. This feature was introduced in 1.10 with macOS and Linux support. Now with version 1.12, multi-app run can be used on Windows as well.
Multi-app run for Kubernetes
Multi-app run has been extended with a preview feature that allows launching multiple apps with container images on Kubernetes.
You can use this feature by running:
The command loads a <inline-h>dapr.yaml<inline-h> file that specifies the applications, with their container image resources. Here’s an example that contains a Node service and a Python app:
See the docs for all the configuration options.
What is next?
This post is not a complete list of features and changes released in version 1.12. 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.
Subscribe today for exclusive Dapr insights