dapr
Update pubsub example.
Description
I add an example about how to pub and how to sub in .NET SDK.
What's Include
An ASP.NET WebAPI project named Publisher shows how to publish with custom model.
An ASP.NET WebAPI project named DeclarativeSubscriber shows how to subscribe topic by yaml file(Declarative) and deal the event.
An ASP.NET WebAPI project named ProgrammaticSubscriber shows how to subscribe topic by coding(Programmatic) and deal the event.
Thanks for your contribution! I've left a few comments.
Overall, is there a reason why you felt this needed to be a totally new example? A pubsub example already exists in the SDK. I'm OK with making a new one, I just want to make sure we know what we're adding.
Also, I'd change the Subscriber names. Instead of
SubscriberandAnotherSubscriberI'd make it explicit. NamesDeclarativeSubscriberandProgrammaticSubscribermake it clear what we're doing without even looking at the code.
thank you for your review, I will update them soon. And about why I feel this to be a totally new example, here's my thought.
It's the clear way to learn about pubsub. To separate the project in examples by building blocks is more clear for learner.
Like me,I was a new Daprer, and I did not know about TopicAttribute type immediately. There's nothing about how to subscribe topic in NET SDK doc, only how to publish. Getting started with the Dapr client .NET SDK
so I was practising this pubsub building block,and it is why I build these three sub samples.
Thanks for addressing the feedback! I have a few more questions.
- Do you think we can combine any of projects? I'm thinking specifically the programmatic ones. They don't need to be 2 projects but rather 2 controllers in the same project. This will cut down on a lot of boiler plate but still makes sense organizationally to me.
- I think the topics should be different for each method. When you have multiple subscribers to the same topic, you can get weird behavior depending on the underlying pubsub component.
About question 1: I try to combine these as one project, and it created a new problem. In the General way controller,I exposed an HTTPGet API routed to "/dapr/subscribe". And in the dotnet way controller, I used TopicAttribute.
But it seems that the TopicAttribute is also exposed an API routed to "/dapr/subscribe". these 2 controllers can only work with one sub behavior. I had to comment the sub behavior code of one of them. I can't find a nice way.
About question 2: In this example,I let them be different.Maybe it should has a fully test in all pubsub brokers.
Thanks for addressing the feedback! I have a few more questions.
- Do you think we can combine any of projects? I'm thinking specifically the programmatic ones. They don't need to be 2 projects but rather 2 controllers in the same project. This will cut down on a lot of boiler plate but still makes sense organizationally to me.
- I think the topics should be different for each method. When you have multiple subscribers to the same topic, you can get weird behavior depending on the underlying pubsub component.
Yes, of cause. You can combine any projects.I've combined subscriber projects to 1. see the latest commit.
Is there an issue describing this? This is a really large PR and I'm not really sure what this is for. We are pretty intentional with accepting new sample content because it's something that have to document and maintain.
nope, maybe this example is too old to compatibility with the latest version