Adding instance-based CreateInvokableHttpClient #1319
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
After installing the
Dapr.Client
NuGet package, there exists a method on aDaprClient
calledCreateInvokeHttpClient
which accepts anappId
, adaprEndpoint
and adaprApiToken
argument and produces anHttpClient
that can be used to send well-formed HTTP requests to other applications accessible by Dapr.After installing the
Dapr.Client.AspNetCore
package, developer get some extensions that simplify the registration of a DaprClient so it can be injected into downstream classes. This is great because especially if the developer is using a non-standard HTTP endpoint or is utilizing the Dapr API token, either can be retrieved in one place, registered in the Dapr client and later uses of the client can just be invoked - no need to keep retrieving those for new invocations.I'd like to marry the two ideas - because
CreateInvokeHttpClient
is a static method on a DaprClient, it doesn't contain any of the properties set on a DI-registered DaprClient, so each invocation requires that I retrieve thedaprApiToken
anddaprEndpoint
values all over again, which simply doesn't make sense as I've already done it once at registration for all other instance-based operations.This PR does just that - it takes the implementation of the static method and puts it into the DaprClient instance, pulling from the existing
apiTokenHeader
on the instance to populate thedaprApiToken
, pulling the endpoint from the instance'shttpEndpoint
value and accepting only anappId
argument so as to specify the ID of the Dapr app to connect to and place in the resulting URI.This way, a developer can register an instance of a DaprClient using a configured Dapr API token and non-standard HTTP endpoint once, and build an HttpClient from that instance that is already configured with these values when they want to invoke other Dapr endpoints without using the service invocation methods (enabling with the instance what they can already do with the static approach, minus the configured values).
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close:
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list: