-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/actor #12
base: main
Are you sure you want to change the base?
Feature/actor #12
Conversation
…NestJS dependencies using a patched ActorManager.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. My only comment would be around testing. In the examples folder there's a docker compose file which stands up a complete dockerised dapr instance without requiring the dapr cli, which I note you've annotated the usage in the tests. Using the docker compose might be useful if you want to use GitHub Actions CI to avoid manual test runs.
Aside from that happy to approve. Also, I'm unlikely to be able to support this code in the short-term - I'm happy to transfer ownership.
Once this is merged, let me know. Happy to create a pipeline - I'm doing a lot of work in CI atm |
Let me sort out the testing part. I'll ensure the docker side is working. |
…. Updated tests. Updated version.
Please provide feedback.
To get the DI to work for Actors the ActorManager from the Dapr SDK had to be monkey patched. This is obviously something we don't want to do, but until I make a PR to allow a "hook" into the Dapr SDK there is no other way.
The next problem is that the ActorClient's new up a HttpClient for every new invocation to each actor type. This is awful and I have found the offending section of the Dapr SDK and will have to submit a PR for that too.
An example actor is:
And a typical NestJS controller can now just call the ActorClient to invoke actors, even if they are on other nodes.