Add support to provide Pubsub (and Topic) during runtime at startup for controller methods.

Describe the proposal

Pubsub name might not be known at compile time, so it would be reasonable to have an approach to specify it during runtime at startup. It’s currently possible if mapping endpoints directly (https://github.com/dapr/dotnet-sdk/blob/master/src/Dapr.AspNetCore/DaprEndpointConventionBuilderExtensions.cs), but not possible for methods within a controller.

My proposal is to make it possible to resolve Pubsub (and Topic) from an environment variable when specified in the TopicAttribute. This is e.g. possible in Azure Functions with most of the attributes there. This would allow us to use the attribute as follows:

[Topic("%MyPubSub%", "%MyTopic%")]
[HttpPost("onEvent")]
public async Task<IActionResult> OnEvent([FromBody] Event data)
{
}

%MyPubSub% and %MyTopic% can then be resolved from an environment variable using e.g. Environment.ExpandEnvironmentVariables, or using a more sophisticated approach as Azure Functions SDK (see NameResolverExtensions.cs).

Another approach would be to add an overload to MapSubscribeHandler to somehow override the values specified in TopicAttribute. Don’t know what the best approach would be here yet… Currently, to workaround this, I’ve just created my own MapSubscribeHandler which takes a string parameter for overriding the PubSub name.

[rynowak]

One obvious way is to implement a custom attribute (which implements the ITopicMetadata interface) and handle the logic there.

Yes. This is the pretty simple case. You get to write custom code to compute the topic name based on whatever inputs you like, as long as they are available from statics + attribute constructor.

These are useful because you can build your own conventions, or consider extra data sources like env-vars.

Are there other ways of adding metadata to endpoints within a controller? A quick google didn’t yield much info about this topic.

Yes, you can do this via application model and write your own code to configure the model.

The reason I like the attribute-based approach is that it’s pretty easy to understand. Technically it doesn’t enable anything that new that’s impossible today.

Application model on the other hand is somewhat involved to understand and work with.

[andreatosato]

I create my TopicEnvAttribute and pass environment variable to ctor