Preview features

List of current preview features

Preview features in Dapr are considered experimental when they are first released.

Runtime preview features require explicit opt-in in order to be used. The runtime opt-in is specified in a preview setting feature in Dapr’s application configuration. See How-To: Enable preview features for more information.

For CLI there is no explicit opt-in, just the version that this was first made available.

Current preview features

FeatureDescriptionSettingDocumentationVersion introduced
App MiddlewareAllow middleware components to be executed when making service-to-service callsN/AApp Middlewarev1.9
Streaming for HTTP service invocationEnables (partial) support for using streams in HTTP service invocation; see below for more details.ServiceInvocationStreamingDetailsv1.10
Pluggable componentsAllows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, BindingsN/APluggable components conceptv1.9
Multi-App RunConfigure multiple Dapr applications from a single configuration file and run from a single commanddapr run -fMulti-App Runv1.10
WorkflowsAuthor workflows as code to automate and orchestrate tasks within your application, like messaging, state management, and failure handlingN/AWorkflows conceptv1.10
CryptographyEncrypt or decrypt data without having to manage secrets keysN/ACryptography conceptv1.11
Service invocation for non-Dapr endpointsAllow the invocation of non-Dapr endpoints by Dapr using the Service invocation API. Read “How-To: Invoke Non-Dapr Endpoints using HTTP” for more information.N/AService invocation APIv1.11
Actor State TTLAllow actors to save records to state stores with Time To Live (TTL) set to automatically clean up old data. In its current implementation, actor state with TTL may not be reflected correctly by clients, read Actor State Transactions for more information.ActorStateTTLActor State Transactionsv1.11

Streaming for HTTP service invocation

Running Dapr with the ServiceInvocationStreaming feature flag enables partial support for handling data as a stream in HTTP service invocation. This can offer improvements in performance and memory utilization when using Dapr to invoke another service using HTTP with large request or response bodies.

The table below summarizes the current state of support for streaming in HTTP service invocation in Dapr, including the impact of enabling ServiceInvocationStreaming, in the example where “app A” is invoking “app B” using Dapr. There are six steps in the data flow, with various levels of support for handling data as a stream:

Diagram showing the steps of service invocation described in the table below

StepHandles data as a streamDapr 1.11Dapr 1.11 with
ServiceInvocationStreaming
1Request: “App A” to “Dapr sidecar A❌❌
2Request: “Dapr sidecar A” to “Dapr sidecar B❌✅
3Request: “Dapr sidecar B” to “App B”✅✅
4Response: “App B” to “Dapr sidecar B”✅✅
5Response: “Dapr sidecar B” to “Dapr sidecar A❌✅
6Response: “Dapr sidecar A” to “App A❌❌

Important notes:

  • ServiceInvocationStreaming needs to be applied on caller sidecars only.
    In the example above, streams are used for HTTP service invocation if ServiceInvocationStreaming is applied to the configuration of “app A” and its Dapr sidecar, regardless of whether the feature flag is enabled for “app B” and its sidecar.
  • When ServiceInvocationStreaming is enabled, you should make sure that all services your app invokes using Dapr (“app B”) are updated to Dapr 1.10 or higher, even if ServiceInvocationStreaming is not enabled for those sidecars.
    Invoking an app using Dapr 1.9 or older is still possible, but those calls may fail unless you have applied a Dapr Resiliency policy with retries enabled.

Full support for streaming for HTTP service invocation will be completed in a future Dapr version.

Last modified June 19, 2023: Merge pull request #3565 from dapr/aacrawfi/skip-secrets-close (b1763bf)