dapr / dotnet-sdk

Dapr SDK for .NET
Apache License 2.0
1.11k stars 339 forks source link

Where is Dapr.Messaging? #1402

Open maxiptah opened 2 weeks ago

maxiptah commented 2 weeks ago

I wanted to follow this example to programmatically subscribe to topics: https://github.com/dapr/dotnet-sdk/blob/master/examples/Client/PublishSubscribe/StreamingSubscriptionExample/Program.cs

That would be a streaming subscription in Dapr terms.

I've installed I think all nuget Dapr packages, but I don't get access to Messaging namespace. Method builder.Services.AddDaprPubSubClient(); is not available.

WhitWaldo commented 2 weeks ago

It will be distributed on NuGet with the 1.15 release in about a month, but it's a brand new package.

If you've cloned the .NET SDK repo (as it appears you have), you can find it at /src/Dapr.Messaging and that example should work given that it uses a project reference instead of a NuGet package.

Some more thoughts - the bits in dapr/dotnet-sdk in the master branch are as fresh as they come and we've been merging in a lot lately. Examples in the Quickstarts rely on the NuGet packages that are actually out there and will be updated after 1.15 to reflect the new packages.

Other new packages you might see that aren't released yet: Dapr.AI and Dapr.Jobs

maxiptah commented 2 weeks ago

Ok, thank you for the info! Thought so, but was confused by some posts on the Internet that said it's a feature in 1.14.

Basically, my use case was creating subscriptions once on application start programmatically. The list of topics was coming from a configuration file. So I searched for a dynamic way to create them because the official way in the docu would be with an attribute: app.MapPost("/orders", [Topic("pubsub", "orders")] (Order order) => {}); This of course makes dynamic creation impossible, as you cannot use variables in attributes.

However, this worked for me: app.MapPost("/orders", (Order order) => {}).WithTopic("pubsub", "orders");. Is there a potential problem with this approach? If not, it would probably be nice to point out this possibility in the docs.

theperm commented 1 week ago

I was not aware that approach was possible, thats very interesting. I guess its not fully dynamic, in the sense it it cant be changed after the endpoint is mapped/app is run but at least you can change it pre startup from some configuration vs having to rebuild the project due to using AOP.

I assume this what you do, change config file, and restart the app? I was thinking though, would using the declarative approach with hot-reload not be a better solution? Change the subscription component in k8s and the service will pick up the changes?

WhitWaldo commented 1 week ago

@maxiptah Yes, the feature itself was released on the Dapr runtime itself in 1.14 and if you're using the HTTP or gRPC APIs directly, you can start using it today. But if you're wanting to use the .NET SDK that simplifies using this new capability, that will come with the 1.15 release in early December. It's already merged, as you noted in the repository, but just because the example, documentation and SDK bits are in master, we haven't actually cut a release to NuGet yet with the new package.

That approach is just using the existing subscription capability. I agree - the .NET docs could use some updates to better reflect the difference between the three approaches (configuration, static programmatic and dynamic programmatic (new)) and I'll see what I can get done before the release next month on that front. Using the topic attribute means that if you want to subscribe to new topics, you're going to need to rebuild the application. That's more than fine and it's been how this works to date, but the new capability lets you programmatically subscribe to new topics on the fly without a recompilation - just know the name of the component and your queue/topic and provide the necessary handler to process the inbound messages.

To your point, no, I don't see anything wrong with using that approach if it's working for you.

@theperm Yes, there's nothing dynamic about specifying WithTopic in the configuration, but that's also not the new capability. We've had that for at least a couple of years. The new capability is described here using the Go SDK (.NET docs are pending) and needs no app recompilation/restart.

If you want to use a configuration-style, that's a supported option as well and documented here with hot-reload preview support.