-
Notifications
You must be signed in to change notification settings - Fork 334
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
Proposal: Strongly-typed non-remoted Actor clients #1158
Comments
@philliphoff - Thanks for writing up this proposal! Sorry it took me a bit to get to it, I saw the PR but somehow missed the proposal associated with it. Overall, I think this is a good idea. My main concern is as follows: Does this require that we make a separate interface for the Client? Or is there a way we can still have this based off the actual implementation and the code generation looks back at the interface and sees the annotations that way? My main concern here is that the two interfaces may get out of sync, which would lead to invocation problems. Though I do see the benefits here in regards to a generated client but for an actor that exists in a different language, so ideally we'd have both. |
It doesn't require separate interfaces; you could still inherit from |
@philliphoff - Thanks for the clarifications! I think this is good to continue as is, looking forward to seeing what we can make out of it :) |
Would it not make sense to also generate strongly types service invocation clients? Ive saw someone use refit but I think the drawback of this is uses an http client and might not use grpc if thats enabled for app protocol |
@theperm If I understand you correctly, you suggest users define an interface that represents all (or some subset) of method invocation supported by an application, then using that interface to generate wrappers around the existing Dapr .NET SDK method invocation method? That's an interesting idea. You might even extend that idea to input/output bindings, too. Those would both be great things to have proposals/contributions for. |
Overview
The Dapr .NET SDK offers two means to invoke methods of hosted actor instances, via a strongly-typed "remoted" proxy* or via an untyped "non-remoted" proxy. There are advantages and disadvantages to both approaches.
Remoted proxy:
public
IActor
record
types)GetStateAsync()
)Non-remoted proxy:
record
types)Neither approach may be an exact fit for developer's needs.
await/async
patterns even if the hosted actor interface does notProposal
I propose the .NET SDK offer strongly-typed non-remoted actor clients, using .NET source generators to generate strongly-typed actor interface implementations built upon the existing non-remoted
ActorProxy
proxy.This approach would enable the following
internal
(as source generators operate "inside" the client assembly)Non-goals
Support for multiple arguments per method invocation
While source generators could be used to offer similar multi-argument serialization, given the ease with which values can be bundled together by the client, I believe there is little need for this capability and it is a capability that could be added later upon sufficient demand.
Design
Actors Generators Package
The source generator(s) would be implemented and distributed in a new NuGet package,
Dapr.Actors.Generators
. This NuGet package would be added as a reference to client projects but using theOutputItemType=Analyzer
.Actor Client Generation
Suppose the client/host defines the actor interface:
The current remoted proxy invocation pattern would be:
The current non-remoted proxy invocation pattern would be:
As mentioned above, both of these approaches have a number of caveats.
Instead, the developer could indicate the desire to generate an actor client using a completely independent interface definition from that of the hosted actor:
Items to note:
GenerateActorClientAttribute
internal
IActor
ActorMethodAttribute
async/await
patterns (e.g. acceptingCancellationToken
) even if the host actor interface does notThe generated client would be:
Generated Client Use
The new proxy invocation pattern would be:
Notes
The text was updated successfully, but these errors were encountered: