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

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

Subscribe to configuration changes

GET http://localhost:<daprPort>/v1.0/configuration/<storeName>/subscribe

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 HTTPEndpoint resource type.
   

   GET http://localhost:<daprPort>/v1.0/invoke/<HTTPEndpoint-name>/method/<my-method>
   

   The HTTPEndpoint resource is specified in a yaml file:
   

   apiVersion: dapr.io/v1alpha1
   kind: HTTPEndpoint
   metadata:
     name: <NAME>  
   spec:
     version: v1alpha1
     baseUrl: <REPLACE-WITH-BASEURL> # Required. Use "http://" or "https://" prefix.
     headers: # Optional
     - name: <REPLACE-WITH-A-HEADER-NAME>
       value: <REPLACE-WITH-A-HEADER-VALUE>
     - name: <REPLACE-WITH-A-HEADER-NAME>
       secretKeyRef:
         name: <REPLACE-WITH-SECRET-NAME>
         key: <REPLACE-WITH-SECRET-KEY>
   scopes: # Optional
     - <REPLACE-WITH-SCOPED-APPIDS>
   auth: # Optional
     secretStore: <REPLACE-WITH-SECRETSTORE>
   

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

   GET http://localhost:<daprPort>/v1.0/invoke/<FQDN_URL>/method/<my-method>
   

Workflow updates

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:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/start
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/terminate
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/pause
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/resume
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/purge
POST http://localhost:<daprPort>/v1.0-alpha1/workflows/dapr/<instanceID>/raiseEvent/<eventName>

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 🆕

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

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

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

• Azure Key Vault: enables cryptography functionality using Azure Key Vault.
• Local storage: enables cryptography functionality using local files. Supported file formats are PEM, JSON Web Key, and raw key data for symmetric keys.
• JWKS: enables cryptography functionality using JSON Web Key Sets (JWKS).
• Kubernetes Secrets: enables cryptography functionality using Kubernetes secrets.

Component improvements

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

• Rate limit: restricts the maximum allowed HTTP requests per second.
• OpenID Connect: verifies a bearer token using OpenID Connect.

Pub/Sub

• GCP Pub/Sub: enables pub/sub messaging using Google Cloud Platform Pub/Sub.

State stores

• GCP Firestore: enables state store functionality using Google Cloud Platform Firestore.
• SQLite: enables state store functionality using SQLite 3.

Configuration stores

• PostgreSQL: enables configuration store functionality using PostgreSQL.
• Redis: enables configuration store functionality using Redis.

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:

• Azure AD Workload Identity on Kubernetes
• Azure CLI credentials.

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.