State
Actor state provides the best of both worlds: it's stored in-memory and persisted automatically. This lets you work with the data without added latency while still being able to survive crashes & upgrades.
State Storage Options
There are multiple ways of storing the state of an actor.
State | API | Use case |
---|---|---|
Native State | this._state | Simple data structures & prototyping |
Local Key-Value State | this._kv | Complex data structures & datasets that cannot fit in memory |
Native state and local key-value state can be used together side-by-side without issue.
Both state options have roughly the same performance.
Using External SQL Databases
Rivet can also be used with external SQL databases. This can be useful to integrate Rivet with existing applications or for storing relational data. Read more here.
State Isolation
Each actor's state is completely isolated, meaning it cannot be accessed directly by other actors or clients. This allows actors to maintain a high level of security and data integrity, ensuring that state changes are controlled and predictable
To interact with an actor's state, you must use Remote Procedure Calls (RPC). RPCs provide a controlled way to read from and write to the state.
Shared State
If you need a shared state between multiple actors, you have two options:
- Create an actor that holds the shared state that actors can make RPCs to
- Use an external database, see External SQL Databases
Native State
Native state is a native JavaScript object stored in-memory on this._state
. This makes building realtime & stateful applications as simple as working with native JavaScript objects.
Initializing & Updating State
Actors with native state require an _initializeState
method. The object returned will be automatically persisted and assigned to this._state
. _initializeState
is only called once when the actor is created. See Lifecycle for more details.
To update state, assign or update this._state
. Any modifications will be automatically persisted.
For example:
Note
Only state stored on the this._state
property will be persisted. All other properties of the Counter
class are kept in-memory and not persisted.
State Saves
Rivet automatically handles persisting state transparently. This happens at the end of every remote procedure call if the state has changed.
In the rare occasion you need to force a state change mid-RPC, you can use _saveState
. This should only be used if your remote procedure call makes an important state change that needs to be persisted before the RPC exits.
Limitations
State is constrained to the available memory (see limitations). For larger datasets, use local KV.
Only JSON-serializable types can be stored in state. State is persisted under the hood in a compact, binary format. This is because JavaScript classes cannot be serialized & deserialized.
Debugging
To debug state, you can use visit the Rivet dashboard and view the state of each actor. This can be useful for understanding the current state of an actor and diagnosing issues. You can also override the method that's used to preview the state in the dashboard. Make sure to not exceed the maximum size of 125MB for the state preview.
Local Key-Value State
KV state is used for storing complex or large datasets that cannot fit into memory. You can access local KV using this._kv
. The KV data is isolated to this actor and cannot be accessed from outside of it.
Keys
Keys used for KV storage can be any JavaScript type that can be cloned via the structured clone algorithm:
Keys can be organized as arrays to simplify usage and enhance security for applications with complex data structures. For example:
It is strongly advised to always use structured keys instead of manually building strings yourself to reduce possible attack vectors from end-users:
Note that single-value keys are automatically converted into single item lists for consistency:
Values
Values stored in the KV can be any JavaScript type which can be cloned via the structured clone algorithm.
KV stores native JavaScript values in a compact binary format so you don't need to write extra serialization & deserialization code.
Binary Data
To store raw binary data, it is recommended to set the format
option in your KV operation to arrayBuffer
and pass in an ArrayBuffer
object. Alternatively, you can put
an ArrayBuffer
or Blob
directly without
changing the format but this has additional space overhead from the JS type system.
Listing & Sorting
Keys are automatically sorted in lexicographic order.
You can use this to list all values under a common prefix key:
Keys are automatically sorted, enabling you to create ordered lists. These ordered lists can scale to millions of entries. For example:
You can also list a subset of keys, which is useful for pagination:
Operations
Raw KV operations can be called via this._kv
.
Operation | Description | Documentation |
---|---|---|
get(key, opts) | Retrieves a value from the key-value store. | Documentation |
getBatch(keys, opts) | Retrieves a batch of key-value pairs. | Documentation |
list(opts) | Retrieves all key-value pairs in the KV store. Uses lexicographic order for filtering. | Documentation |
put(key, value, opts) | Stores a key-value pair in the key-value store. | Documentation |
putBatch(obj, opts) | Stores a batch of key-value pairs. | Documentation |
delete(key) | Deletes a key-value pair from the key-value store. | Documentation |
deleteBatch(keys) | Deletes a batch of key-value pairs from the key-value store. | Documentation |
deleteAll() | Deletes all data from the key-value store. This CANNOT be undone. | Documentation |
Limitations
See limitations.