Production Reference: Actors

    There are four different modes actor proxies are handled. Each mode presents different trade-offs that you’ll need to weigh during development and in production.

    It can be set with configuration key.

    This is the default mode. In this mode, a class is generated and eval‘d on every request. It’s mostly for development and shouldn’t be used in production.

    This is the same as ProxyModes::GENERATED except the class is stored in a tmp file so it doesn’t need to be regenerated on every request. It doesn’t know when to update the cached class, so using it in development is discouraged but is offered for when manually generating the files isn’t possible.

    In this mode, an exception is thrown if the proxy class doesn’t exist. This is useful for when you don’t want to generate code in production. You’ll have to make sure the class is generated and pre-/autoloaded.

    Create a ProxyCompiler.php

    Then add a psr-4 autoloader for the generated proxies and a script in composer.json:

    And finally, configure dapr to only use the generated proxies:

    In this mode, the proxy satisfies the interface contract, however, it does not actually implement the interface itself (meaning instanceof will be ). This mode takes advantage of a few quirks in PHP to work and exists for cases where code cannot be eval‘d or generated.

    Requests

    Creating an actor proxy is very inexpensive for any mode. There are no requests made when creating an actor proxy object.

    Every actor implementation in PHP must implement \Dapr\Actors\IActor and use the trait. This allows for fast reflection and some shortcuts. Using the \Dapr\Actors\Actor abstract base class does this for you, but if you need to override the default behavior, you can do so by implementing the interface and using the trait.

    When an actor activates, a token file is written to a temporary directory (by default this is in '/tmp/dapr_' + sha256(concat(Dapr type, id)) in linux and '%temp%/dapr_' + sha256(concat(Dapr type, id)) on Windows). This is persisted until the actor deactivates, or the host shuts down. This allows for on_activation to be called once and only once when Dapr activates the actor on the host.

    Actor method invocation is very fast on a production setup with php-fpm and nginx, or IIS on Windows. Even though the actor is constructed on every request, actor state keys are only loaded on-demand and not during each request. However, there is some overhead in loading each key individually. This can be mitigated by storing an array of data in state, trading some usability for speed. It is not recommended doing this from the start, but as an optimization when needed.

    The names of the variables in the object directly correspond to key names in the store. This means that if you change the type or name of a variable, you may run into errors. To get around this, you may need to version your state object. In order to do this, you’ll need to override how state is loaded and stored. There are many ways to approach this, one such solution might be something like this:

    There’s a lot to be optimized, and it wouldn’t be a good idea to use this verbatim in production, but you can get the gist of how it would work. A lot of it will depend on your use case which is why there’s not something like this in the SDK. For instance, in this example implementation, the previous value is kept for where there may be a bug during an upgrade; keeping the previous value allows for running the upgrade again, but you may wish to delete the previous value.