Merge pull request #3648 from hhunter-ms/issue_3592_2

[Bindings] Update bindings docs to include `direction` metadata

daprdocs/content/en/developing-applications/building-blocks/bindings/bindings-overview.md

@@ -57,6 +57,20 @@ To invoke an output binding:
 
 Read the [Use output bindings to interface with external resources guide]({{< ref howto-bindings.md >}}) to get started with output bindings.
 
+## Binding directions (optional)
+
+You can provide the `direction` metadata field to indicate the direction(s) supported by the binding component. In doing so, the Dapr sidecar avoids the `"wait for the app to become ready"` state reducing the lifecycle dependency between the Dapr sidecar and the application:
+
+- `"input"`
+- `"output"`
+- `"input, output"`
+
+{{% alert title="Note" color="primary" %}}
+It is highly recommended that all bindings should include the `direction` property.
+{{% /alert %}}
+
+[See a full example of the bindings `direction` metadata.]({{< ref "bindings_api.md#binding-direction-optional" >}})
+
 ## Try out bindings
 
 ### Quickstarts and tutorials

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md

@@ -32,6 +32,8 @@ Create a new binding component named `checkout`. Within the `metadata` section,
 - The topic to which you'll publish the message
 - The broker
 
+When creating the binding component, [specify the supported `direction` of the binding]({{< ref "bindings_api.md#binding-direction-optional" >}}). 
+
 {{< tabs "Self-Hosted (CLI)" Kubernetes >}}
 
 {{% codetab %}}
@@ -59,7 +61,9 @@ spec:
   - name: publishTopic
     value: sample
   - name: authRequired
-    value: "false"
+    value: false
+  - name: direction
+    value: output
 ```
 
 {{% /codetab %}}
@@ -89,7 +93,9 @@ spec:
   - name: publishTopic
     value: sample
   - name: authRequired
-    value: "false"
+    value: false
+  - name: direction
+    value: output
 ```
 
 {{% /codetab %}}

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md

@@ -37,6 +37,8 @@ Create a new binding component named `checkout`. Within the `metadata` section,
 - The topic to which you'll publish the message
 - The broker
 
+When creating the binding component, [specify the supported `direction` of the binding]({{< ref "bindings_api.md#binding-direction-optional" >}}). 
+
 {{< tabs "Self-Hosted (CLI)" Kubernetes >}}
 
 {{% codetab %}}
@@ -64,7 +66,9 @@ spec:
   - name: publishTopic
     value: sample
   - name: authRequired
-    value: "false"
+    value: false
+  - name: direction
+    value: input
 ```
 
 {{% /codetab %}}
@@ -94,7 +98,9 @@ spec:
   - name: publishTopic
     value: sample
   - name: authRequired
-    value: "false"
+    value: false
+  - name: direction
+    value: input
 ```
 
 {{% /codetab %}}
@@ -256,15 +262,15 @@ async function start() {
 
 {{< /tabs >}}
 
-### ACK-ing an event
+### ACK an event
 
 Tell Dapr you've successfully processed an event in your application by returning a `200 OK` response from your HTTP handler.
 
-### Rejecting an event
+### Reject an event
 
 Tell Dapr the event was not processed correctly in your application and schedule it for redelivery by returning any response other than `200 OK`. For example, a `500 Error`.
 
-### Specifying a custom route
+### Specify a custom route
 
 By default, incoming events will be sent to an HTTP endpoint that corresponds to the name of the input binding. You can override this by setting the following metadata property in `binding.yaml`:
 

daprdocs/content/en/reference/api/bindings_api.md

@@ -40,13 +40,18 @@ If running on kubernetes apply the component to your cluster.
 ### Binding direction (optional)
 
 In some scenarios, it would be useful to provide additional information to Dapr to indicate the direction supported by the binding component. 
-Providing the supported binding direction helps the Dapr sidecar avoid the `"wait for the app to become ready"` state, where it waits indefinitely for the application to become available.
+
+Providing the binding `direction` helps the Dapr sidecar avoid the `"wait for the app to become ready"` state, where it waits indefinitely for the application to become available. This decouples the lifecycle dependency between the Dapr sidecar and the application.
 
 You can specify the `direction` field as part of the component's metadata. The valid values for this field are: 
 - `"input"`
 - `"output"`
 - `"input, output"`
 
+{{% alert title="Note" color="primary" %}}
+It is highly recommended that all bindings should include the `direction` property.
+{{% /alert %}}
+
 Here a few scenarios when the `"direction"` metadata field could help:
 
 - When an application (detached from the sidecar) runs as a serverless workload and is scaled to zero, the `"wait for the app to become ready"` check done by the Dapr sidecar becomes pointless.