Dapr

Dapr logo

Dapr can be used inside the sigMAX runtime model to provide a standard internal communication layer between generated components. It is not the public entry point of the application. Its role is to give each component a local sidecar that can handle service invocation, state access, bindings, pub/sub, secrets, and observability through declared building blocks.

In sigMAX, Dapr is mainly useful when generated components need to call each other or reach infrastructure capabilities without hard-coding host-specific addresses into the generated logic.

What Dapr Is

Dapr is an open source runtime for building distributed applications. It gives application code a set of stable APIs for common distributed-system concerns such as service invocation, state, pub/sub, bindings, secrets and observability.

The important idea is separation: application code keeps its business role, while Dapr carries infrastructure-facing communication patterns through a sidecar runtime named daprd.

Project concern	Dapr contribution
Service-to-service calls	Address services by app identity rather than hard-coded network details.
State and bindings	Use configured components instead of embedding provider-specific clients everywhere.
Pub/sub and events	Route messages through a portable building block.
Secrets and config	Keep provider access behind declared runtime configuration.
Observability	Emit consistent telemetry around distributed calls.

Project Building Blocks

Dapr is organized around building-block APIs. Each block exposes a stable API, while the concrete backing service is configured separately.

Building block	Typical purpose
Service invocation	Call another application through its Dapr app ID.
State management	Read and write state through a configured state store.
Pub/sub	Publish and subscribe to application events.
Bindings	Connect to external systems through input or output bindings.
Secrets	Retrieve secrets from a configured secret store.
Observability	Collect traces, metrics and logs around runtime calls.

How The Sidecar Model Works

In containerized deployments, each application process can run next to a Dapr sidecar. The application calls its local sidecar over HTTP or gRPC. The sidecar then handles the distributed concern: resolving the target app, invoking another sidecar, applying component configuration, or calling a configured infrastructure provider.

This keeps the application container smaller and more stable. It does not need to know whether a dependency is local, remote, backed by Redis, PostgreSQL, a message broker, or another infrastructure service. Those choices live in Dapr component configuration and deployment policy.

Dapr In sigMAX

sigMAX uses Dapr as an internal communication layer, not as the public API. Generated components remain the application endpoints. Dapr sidecars help those components invoke each other and reach internal capabilities without baking environment-specific addresses into generated WASM logic.

sigMAX element	Dapr role
Generated component	Runs the sigMAX runtime and route/WASM logic.
Component sidecar	Gives that component an internal Dapr endpoint.
Storage service	Stays behind a Dapr sidecar and Docker network.
Docker Compose stack	Wires app containers, sidecars and storage together.
Binary Contract	Still decides which runtime primitives and capabilities are allowed.

What Dapr Does Not Replace

Dapr is not the sigMAX runtime, not the contract model, and not the public security boundary. It should not be used to hide undeclared dependencies or bypass the primitive/capability model.

Not replaced	Why it stays separate
Binary Contracts	They define allowed WASM imports, primitives and capabilities.
Rust runtime	It loads WASM modules and enforces the execution boundary.
Public gateway	External exposure should stay explicit and narrow.
Agreements	Generated and observed state still needs validation evidence.

Runtime topology

The diagram below shows the intended shape: external traffic reaches the Rust runtime first. The runtime then calls the generated application components, while Dapr sidecars stay internal to Docker.

Exposure model

Recommended flow:

The important boundary is the difference between application exposure and sidecar exposure:

application ports can be published when they are intended entry points;
Dapr HTTP ports are internal by default;
Dapr sidecars remain implementation details of the internal runtime topology;
generated application components are reached through the runtime boundary;
database access stays behind the Docker network.

This keeps local development inspectable while avoiding a model where every sidecar becomes a public API surface.