diff --git a/daprdocs/content/en/concepts/building-blocks-concept.md b/daprdocs/content/en/concepts/building-blocks-concept.md index f733e0ed4..77bd4d024 100644 --- a/daprdocs/content/en/concepts/building-blocks-concept.md +++ b/daprdocs/content/en/concepts/building-blocks-concept.md @@ -20,12 +20,13 @@ The following are the building blocks provided by Dapr: | Building Block | Endpoint | Description | |----------------|----------|-------------| -| [**Service-to-service invocation**]({{}}) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling. -| [**State management**]({{}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence. -| [**Publish and subscribe**]({{}}) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications. -| [**Bindings**]({{}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service. -| [**Actors**]({{}}) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the virtual actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use. -| [**Observability**]({{}}) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications. -| [**Secrets**]({{}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database. -| [**Configuration**]({{}}) | `/v1.0-alpha1/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store. -| [**Distributed lock**]({{}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees. \ No newline at end of file +| [**Service-to-service invocation**]({{< ref "service-invocation-overview.md" >}}) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling. +| [**State management**]({{< ref "state-management-overview.md" >}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence. +| [**Publish and subscribe**]({{< ref "pubsub-overview.md" >}}) | `/v1.0/publish` `/v1.0/subscribe`| Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications. +| [**Bindings**]({{< ref "bindings-overview.md" >}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the Dapr binding API, and it allows your application to be triggered by events sent by the connected service. +| [**Actors**]({{< ref "actors-overview.md" >}}) | `/v1.0/actors` | An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the virtual actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use. +| [**Observability**]({{< ref "observability-concept.md" >}}) | `N/A` | Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications. +| [**Secrets**]({{< ref "secrets-overview.md" >}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database. +| [**Configuration**]({{< ref "configuration-api-overview.md" >}}) | `/v1.0-alpha1/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store. +| [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees. +| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-alpha1/workflow` | The workflow API enables you to define a processes or data flows that span multiple microservices via an embedded workflow engine. With this built-in workflow engine, you can easily integrate with existing Dapr building blocks while maintaining portability. \ No newline at end of file diff --git a/daprdocs/content/en/concepts/components-concept.md b/daprdocs/content/en/concepts/components-concept.md index 2ec3c936d..c74828af6 100644 --- a/daprdocs/content/en/concepts/components-concept.md +++ b/daprdocs/content/en/concepts/components-concept.md @@ -11,11 +11,11 @@ Dapr uses a modular design where functionality is delivered as a component. Each You can contribute implementations and extend Dapr's component interfaces capabilities via: - The [components-contrib repository](https://github.com/dapr/components-contrib) -- [Pluggable components]({{}}). +- [Pluggable components]({{< ref "components-concept.md#pluggable-components" >}}). -A building block can use any combination of components. For example, the [actors]({{}}) and the [state management]({{}}) building blocks both use [state components](https://github.com/dapr/components-contrib/tree/master/state). +A building block can use any combination of components. For example, the [actors]({{< ref "actors-overview.md" >}}) and the [state management]({{< ref "state-management-overview.md" >}}) building blocks both use [state components](https://github.com/dapr/components-contrib/tree/master/state). -As another example, the [pub/sub]({{}}) building block uses [pub/sub components](https://github.com/dapr/components-contrib/tree/master/pubsub). +As another example, the [pub/sub]({{< ref "pubsub-overview.md" >}}) building block uses [pub/sub components](https://github.com/dapr/components-contrib/tree/master/pubsub). You can get a list of current components available in the hosting environment using the `dapr components` CLI command. @@ -26,9 +26,9 @@ Each component has a specification (or spec) that it conforms to. Components are - A `components/local` folder within your solution, or - Globally in the `.dapr` folder created when invoking `dapr init`. -These YAML files adhere to the generic [Dapr component schema]({{}}), but each is specific to the component specification. +These YAML files adhere to the generic [Dapr component schema]({{< ref "component-schema.md" >}}), but each is specific to the component specification. -It is important to understand that the component spec values, particularly the spec `metadata`, can change between components of the same component type, for example between different state stores, and that some design-time spec values can be overridden at runtime when making requests to a component's API. As a result, it is strongly recommended to review a [component's specs]({{}}), paying particular attention to the sample payloads for requests to set the metadata used to interact with the component. +It is important to understand that the component spec values, particularly the spec `metadata`, can change between components of the same component type, for example between different state stores, and that some design-time spec values can be overridden at runtime when making requests to a component's API. As a result, it is strongly recommended to review a [component's specs]({{< ref "components-reference" >}}), paying particular attention to the sample payloads for requests to set the metadata used to interact with the component. The diagram below shows some examples of the components for each component type @@ -46,7 +46,7 @@ For example: - Your component may be specific to your company or pose IP concerns, so it cannot be included in the Dapr component repo. - You want decouple your component updates from the Dapr release cycle. -For more information read [Pluggable components overview]({{}}) +For more information read [Pluggable components overview]({{< ref "pluggable-components-overview" >}}) ## Available component types @@ -61,7 +61,7 @@ State store components are data stores (databases, files, memory) that store key ### Name resolution -Name resolution components are used with the [service invocation]({{}}) building block to integrate with the hosting environment and provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component. +Name resolution components are used with the [service invocation]({{< ref "service-invocation-overview.md" >}}) building block to integrate with the hosting environment and provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component. - [List of name resolution components]({{< ref supported-name-resolution >}}) - [Name resolution implementations](https://github.com/dapr/components-contrib/tree/master/nameresolution) @@ -82,7 +82,7 @@ External resources can connect to Dapr in order to trigger a method on an applic ### Secret stores -A [secret]({{}}) is any piece of private information that you want to guard against unwanted access. Secrets stores are used to store secrets that can be retrieved and used in applications. +A [secret]({{< ref "secrets-overview.md" >}}) is any piece of private information that you want to guard against unwanted access. Secrets stores are used to store secrets that can be retrieved and used in applications. - [List of supported secret stores]({{< ref supported-secret-stores >}}) - [Secret store implementations](https://github.com/dapr/components-contrib/tree/master/secretstores) @@ -101,9 +101,16 @@ Lock components are used as a distributed lock to provide mutually exclusive acc - [List of supported locks]({{< ref supported-locks >}}) - [Lock implementations](https://github.com/dapr/components-contrib/tree/master/lock) +### Workflows + +A [workflow]({{< ref workflow-overview.md >}}) is custom application logic that defines business process or data flow in a reliable way across mulitple microservices. The workflow API is exposed by a [lightweight, embedded workflow engine]({{< ref "operations/components/workflow-engine/workflow-engine.md" >}}) in the Dapr sidecar, allowing you to easily integrate with existing Dapr building blocks. + +- [List of supported workflows]({{< ref supported-workflows >}}) +- Workflow implementations + ### Middleware -Dapr allows custom [middleware]({{}}) to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request (such as authentication, encryption, and message transformation) before the request is routed to the user code, or the response is returned to the client. The middleware components are used with the [service invocation]({{}}) building block. +Dapr allows custom [middleware]({{< ref "middleware.md" >}}) to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request (such as authentication, encryption, and message transformation) before the request is routed to the user code, or the response is returned to the client. The middleware components are used with the [service invocation]({{< ref "service-invocation-overview.md" >}}) building block. - [List of supported middleware components]({{< ref supported-middleware >}}) - [Middleware implementations](https://github.com/dapr/components-contrib/tree/master/middleware) diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md index b0fdc31af..f72198fb1 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md @@ -33,24 +33,7 @@ A workflow's utility for microservices makes it a great fit for Dapr’s mission | An efficient, more manageable single sidecar for all microservices | Separate sidecars (or services) for workflows. | | Portable workflows keeps Dapr portable. | Lessened portability. | -With a [lightweight, embedded workflow engine](#embedded-workflow-engine), you can create orchestration on top of existing Dapr building blocks in a portable and adoptable way. The workflow building block consists of: - -- A pluggable component model for integrating various workflow engines -- A set of APIs for managing workflows (start, schedule, pause, resume, cancel) - -Workflows supported by your platforms can be exposed as APIs with support for both HTTP and the Dapr SDKs, including: - -- mTLS, distributed tracing, etc. -- Various abstractions, such as async HTTP polling - -### Sidecar interactions and the Dapr SDK - -Behind the scenes, the `DaprWorkflowClient` SDK object handles all the interactions with the Dapr sidecar, including: - -- Responding to invocation requests from the Dapr sidecar. -- Sending the necessary commands to the Dapr sidecar as the workflow progresses. -- Checkpointing the progress so that the workflow can be resumed after any infrastructure failures. - +With a [lightweight, embedded workflow engine](#embedded-workflow-engine), you can create orchestration on top of existing Dapr building blocks in a portable and adoptable way.