You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The below code examples loosely describe the scenario of a Parking Garage Spot Monitoring System, which can be seen in this [video] by Mark Russinovich(https://www.youtube.com/watch?v=eJCu6a-x9uo&t=3785).
20
+
The below code examples loosely describe the scenario of a Parking Garage Spot Monitoring System, which can be seen in this [video](https://www.youtube.com/watch?v=eJCu6a-x9uo&t=3785) by Mark Russinovich.
21
21
22
-
A parking garage consists of hundreds of parking spaces, where each parking space includes a sensor that provides updates to a centralized monitoring system. The parking space sensors (our actors) detect if a parking space is occupied, or available.
22
+
A parking garage consists of hundreds of parking spaces, where each parking space includes a sensor that provides updates to a centralized monitoring system. The parking space sensors (our actors) detect if a parking space is occupied or available.
23
23
24
24
To jump in and run this example yourself, clone the source code, which can be found in the [JavaScript SDK examples directory](https://github.com/dapr/js-sdk/tree/master/examples/http/actor-parking-sensor).
25
25
26
26
## Actor Interface
27
27
The actor interface defines the contract that is shared between the actor implementation and the clients calling the actor. In the example below, we have created an interace for a parking garage sensor. Each sensor has 2 methods: `carEnter` and `carLeave`, which defines the state of the parking space:
28
28
29
-
```javascript
29
+
```ts
30
30
exportdefaultinterfaceParkingSensorInterface {
31
31
carEnter():Promise<void>;
32
32
carLeave():Promise<void>;
33
33
}
34
34
```
35
35
36
36
## Actor Implementation
37
-
An actor implementation defines a class by extending the base type `AbstractActor` and implements the actor interface. The following code describes what an actor implmentation consists of by implementing the methods defined in the `ParkingSensorInterface`. It also defines a few extra helper methods:
37
+
An actor implementation defines a class by extending the base type `AbstractActor` and implementing the actor interface (`ParkingSensorInterface` in this case).
38
38
39
-
```javascript
39
+
The following code describes an actor implementation along with a few helper methods.
After Actors are registered, use the DaprClient to invoke methods on an actor. The client will call the actor methods defined in the actor interface.
90
+
## Invoking Actor Methods
91
+
After Actors are registered, create a Proxy object that implements `ParkingSensorInterface` using the `ActorProxyBuilder`. You can invoke the actor methods by directly calling methods on the Proxy object. Internally, it translates to making a network call to the Actor API and fetches the result back.
The JS SDK supports actors that can schedule periodic work on themselves by registering either timers or reminders. The main difference between timers and reminders is that the Dapr actor runtime is not retaining any information about timers after deactivation, while persisting the information about reminders using the Dapr actor state provider.
139
+
The JS SDK supports actors that can schedule periodic work on themselves by registering either timers or reminders. The main difference between timers and reminders is that the Dapr actor runtime does not retain any information about timers after deactivation, but persists reminders information using the Dapr actor state provider.
139
140
140
-
This distintcion allows users to trade off between light-weight but stateless timers vs. more resource-demanding but stateful reminders.
141
+
This distinction allows users to trade off between light-weight but stateless timers versus more resource-demanding but stateful reminders.
141
142
142
143
The scheduling interface of timers and reminders is identical. For an more in-depth look at the scheduling configurations see the [actors timers and reminders docs]({{< ref "howto-actors.md#actor-timers-and-reminders" >}}).
To handle the callback, you need to override the default `receiveReminder` implementation in your actor. For example, from our original actor implementation:
This example shows a car parking area where cars (virtual actors) enter and leave randomly. The car sensor data is sent via Dapr actors to InfluxDB and displayed on Grafana.
4
+
5
+
## Prerequisites
6
+
7
+
Start influxdb, telegraf and grafana using docker-compose.
4
8
5
9
```bash
6
-
# Run InfluxDB
7
-
# Note: it auto removes after shutdown
8
-
# Note: non-persistent volume, add "-v influxdb2:/var/lib/influxdb2" to make it persistent
9
-
docker run --rm -it -d \
10
-
-e DOCKER_INFLUXDB_INIT_MODE=setup \
11
-
-e DOCKER_INFLUXDB_INIT_USERNAME=admin \
12
-
-e DOCKER_INFLUXDB_INIT_PASSWORD=MyAdmin@123! \
13
-
-e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=my-token \
14
-
-e DOCKER_INFLUXDB_INIT_ORG=my-parking-garage \
15
-
-e DOCKER_INFLUXDB_INIT_BUCKET=my-sensors \
16
-
--net=host \
17
-
--name influxdb \
18
-
influxdb:2.0
19
-
20
-
# Run Telegraf
21
-
docker run --rm -it -d \
22
-
--net=host \
23
-
--name=telegraf \
24
-
telegraf
25
-
26
-
# Run Grafana
27
-
# Note: non-persistent volume, add "-v influxdb2:/var/lib/influxdb2" to make it persistent
28
-
docker run --rm -it -d \
29
-
--name=grafana \
30
-
--net=host \
31
-
grafana/grafana
10
+
docker-compose up
32
11
```
33
12
34
13
## Running
@@ -40,22 +19,18 @@ docker run --rm -it -d \
40
19
# Install (from the example directory)
41
20
npm install
42
21
43
-
# Start a RabbitMQ Container (for the binding example part)
44
-
# note: mgmt interface at http://localhost:15672
45
-
docker run -d --rm --hostname my-rabbitmq --name my-rabbitmq \
0 commit comments