-
Notifications
You must be signed in to change notification settings - Fork 15
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
Publish to queue? #89
Comments
Thanks for the feedback! We currently have a generic
We also have the service-specific publishers such as
I think we're open to separating the service-specific interfaces and implementations like how you suggested:
But we're more on the fence for adjusting the generic publisher. I think we want to keep it overall since it's simpler if one doesn't need to take advance of service-specific features. I'm curious about your thoughts on:
|
We shipped renaming of the service-specific publishers today 0.2.0-beta via #101. The names now match the proposal above
Let us know if you have any other feedback on design or naming, thanks! |
Hi @ashovlin Sorry for the delayed feedback. I started a new job recently which has taken all my attention. I did read your first comments but forgot to get back to you. I like the changes you have made, differentiating the My only remaining thought is that, looking at this purely from an consumer/outsider's perpective, it is odd to see a One other (unrelated) piece of feedback is that your might want to run FxCop (or what we call "Code Analysis" these days) over the code base because the .NET coding standards state that acronyms of three or more letters should be pascal cased. See: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions#capitalization-rules-for-identifiers In this code base this would mean to use Sqs and Sns instead of SQS and SNS respectively, giving Thanks very much for considering and actioning the feedback. |
For what it is worth, I really like this. Please don’t change it by having Publish and Send as different methods on that interface. |
Adding support for both of @CallumHibbert's comments.
There are other frameworks I've worked with that support these types of naming conventions and very clearly delineate the logical as physical differences between commands and events. Enterprise Integration Patterns:
NServiceBus Message Bus: MassTransit |
Any chance you'd be open to a pull request to explore the API changes mentioned above in terms of sending a message to a queue vs. publishing a message to a topic? |
System design with messaging must be done carefully and should follow fairly strict principles. One such principle is the difference between commands and events.
Put very simply, a command is an instruction to do something and should be sent (not published) to a specific recipient. Sending to a specific recipient infers using a queue. In AWS world this means using SQS.
An event is a notification that something happened and should be published (not sent) with the publisher not really aware of the subscribers. Publishing infers using a topic. In AWS world this means SNS or possibly Event Bridge.
There is a clear distinction between "send" vs "publish", what those operations do and how they work.
These principles are really important to achieve good system design and the current API doesn't follow these. In the context of the above principles, an "SQS publisher" (as provided by the library) does not make sense (you shouldn't "publish" to a "queue").
Going directly to a proposed alternative, consider one interface with differing methods e.g.
Or two different interfaces e.g.
This encourages consumers to follow a system design better aligned with correct messaging principles.
The text was updated successfully, but these errors were encountered: