All Blogs

Dapr v1.11 Release Highlights

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

The Dapr maintainers released a new version of Dapr, the distributed application runtime, this 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

Configuration API

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:/v1.0/configuration/?key=

Copy to Clipboard Copied

Subscribe to configuration changes



GET http://localhost:/v1.0/configuration//subscribe

Copy to Clipboard Copied

Service Invocation for non-Dapr endpoints ๐Ÿ†•

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:

1. Using an <inline-h>HTTPEndpoint<inline-h> resource type.



GET http://localhost:/v1.0/invoke//method/

Copy to Clipboard Copied

2. The HTTPEndpoint resource is specified in a yaml file:



apiVersion: dapr.io/v1alpha1
kind: HTTPEndpoint
metadata:
name:
spec:
version: v1alpha1
baseUrl: # Required. Use "http://" or "https://" prefix.
headers: # Optional
- name:
value:
- name:
secretKeyRef:
name:
key:
scopes: # Optional
-
auth: # Optional
secretStore:

Copy to Clipboard Copied

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



GET http://localhost:/v1.0/invoke//method/

Copy to Clipboard Copied

Workflow updates

Workflow management API

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:/v1.0-alpha1/workflows/dapr/start?instanceID=POST http://localhost:/v1.0-alpha1/workflows/dapr//terminatePOST http://localhost:/v1.0-alpha1/workflows/dapr//pausePOST http://localhost:/v1.0-alpha1/workflows/dapr//resumePOST http://localhost:/v1.0-alpha1/workflows/dapr//purgePOST http://localhost:/v1.0-alpha1/workflows/dapr//raiseEvent/

Copy to Clipboard Copied

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 ๐Ÿ†•

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",
});

Copy to Clipboard Copied

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",
});

Copy to Clipboard Copied

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

Component improvements

Component Lifecycle

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

Pub/Sub

State stores

Configuration stores

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:

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.

โ€