Dapr
Dapr provides an internal communication layer for sigMAX services. The Rust host calls a configured sidecar; generated WASM handlers use named primitives and bindings instead of addressing sidecars or infrastructure directly.
The current implementation includes Dapr service invocation, event publication and output bindings. A Dapr capability is usable by a handler only when the sigMAX runtime and route policy expose it.
Request Path
Section titled “Request Path”The generated component already contains the Rust runtime. There is no additional standalone Rust gateway in front of every component.
The amber host check precedes the violet sidecar boundary. The diagram follows one Dapr-backed operation; the configured binding selects this path. A target reaches a database or object store only when that service or adapter owns the integration. Other host operations, such as the shared cache, use their own configured backend.
The deployment can place an ingress or authenticated proxy before the component. Sidecars remain internal service endpoints.
Implemented Building Blocks
Section titled “Implemented Building Blocks”| Operation | Host behavior |
|---|---|
| Service invocation | Resolves an app ID, method and HTTP verb from a declared binding. |
| Event publication | Resolves the configured pub/sub component and logical topic. |
| Output bindings | Calls a configured component operation with a bounded payload. |
| Typed calls | Converts between c_repr values and the service’s JSON representation. |
The implementation in runtime/src/dapr.rs supports service invocation with GET, POST, PUT, PATCH and DELETE. GET and DELETE inputs become scalar query parameters; other supported verbs send JSON. The client applies deadlines to requests and response consumption.
Bindings And Capabilities
Section titled “Bindings And Capabilities”A route binding keeps infrastructure details in host configuration. The handler selects its logical name, and the host checks required capabilities before making the call.
For example, a storage handler can call a binding named storage.invoice.get. The binding identifies the target storage app and operation; the WASM module does not receive a PostgreSQL connection string. See Storage service.
Events and blobs follow the same separation. The physical Dapr component and topic belong to host-owned configuration, while the contract declares the effects the business handler may request.
File storage distinguishes the MinIO file service from the dapr_blob adapter contract. Runtime integrations covers event publication, cache and authenticated identity; cache operations do not require a Dapr sidecar.
Deployment
Section titled “Deployment”Core uses Docker Compose for Host and Config on one machine. The inspected development topology controls generated component and Dapr containers through the Docker Engine API. Each component has its own sidecar endpoint supplied through DAPR_HTTP_ENDPOINT.
The Pro architecture uses Kubernetes and the COS2000 executor in a KubeVirt VM. The executor boundary does not give business code direct access to Dapr. Host-mediated calls and their capabilities remain part of the integration contract.
What Dapr Does Not Decide
Section titled “What Dapr Does Not Decide”Dapr does not decide which WASM imports a binary may use, which business operation a route is authorized to perform, or whether generated artifacts match their agreements. Those checks belong to the sigMAX compiler, host and validation pipeline.
Sidecar telemetry can help inspect distributed calls. Its presence alone does not prove that every application span is exported; see Observability.