The following scenario is implemented here.
My service simply stores some data in a data store. But, it does not access the data store directly. Instead, it passes the data to its dapr sidecar and instructs it to store the data. Thus, dapr completely abstracts the underlying data store for My service.
- dapr CLI
- Java (Version >=17)
Install dapr on your system. This will start a redis docker container by default.
dapr init
./gradlew buildFatJar
dapr run --app-id my-service --app-port 8080 --app-protocol http --dapr-http-port 3500 --components-path components/local/ -- java -cp build/libs/fat.jar com.example.MyServiceKt
As you can see, the dapr CLI is used to start up both, the dapr sidecar and the service.
curl http://localhost:8080
dapr supports many data stores. A yaml config file specifies which concrete state store implementation is used for a project. This enables us to exchange the underlying state store implementation without making any code changes.
Each component has a specification (or spec) that it conforms to. Components are configured at design-time with a YAML file which is stored in either:
- A
components/local
folder within your solution, or - Globally in the
.dapr
folder created when invokingdapr init
.
In this project, the configuration file is placed inside the solution (components/local
).