Skip to content
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

"topic" using in Infrasturcture.Message? #26

Closed
kevinding0218 opened this issue Mar 15, 2019 · 2 comments
Closed

"topic" using in Infrasturcture.Message? #26

kevinding0218 opened this issue Mar 15, 2019 · 2 comments

Comments

@kevinding0218
Copy link

Hello Edwin, thank you very much for sharing this tutorial, I am not an expert to RabbitMQ but very exciting to learn. As I am research in this project where in Infrastructure.Messaging.IMessagePublisher, the method you defined as
Task PublishMessageAsync(string messageType, object message, string routingKey);
has an additional description param called
/// <param name="topic">Topic to publish the message to.</param>,
however I didn't see where you declare/implement this type of 'topic' anywhere through the Messaging, I also checked the tutorial through RabbitMQ - Topic , and found that difference by using 'fanout' vs 'direct(topic)', so in this project, I saw you're using 'fanout' through Message publisher, could you please let me know why using 'fanout' instead of 'direct/topic'? Seems to me that we can direct service type A to Process A, service type B to Process B which would be more like a 'direct' way.
Please feel free to let me know if I understand incorrectly. Thank you very much!

@EdwinVW
Copy link
Owner

EdwinVW commented Mar 17, 2019

Hello @kevinding0218, thanks for interest in this project! I hopye you will learn from it.

About your questions:

  1. The topic param in the comments is not supposed to be there. I have removed it from the code. It was a leftover from an earlier version and I forgot to removed it after I refactored the code.
  2. I use a fanout Exchange to do pub-sub. The idea is that every event might be interesting for every consumer. Using fanout, every consumer can define a queue and bind it to the Exchange. This way the sender is unaware of its' consumers, which reduces coupling. Whether this is the right way to distribute your events, totally depends on the situation. For Pitstop there are not many consumers and we control everything in the solution. In a more enterprise-like environment with multiple teams and more consumers, it might be better to distribute your messaging load differently (either using multiple Exchanges, or routing-keys (which I support in the Messaging library) or ...). So I use it like this, but don't assume this is the only way to do messaging.

I hope this makes sense and I've answered your questions.

@kevinding0218
Copy link
Author

Thank you very much Edwin! This makes perfect sense to me!

@EdwinVW EdwinVW closed this as completed Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants