Modern C# native async API

[Gladskih]

I have read (#83 (comment)) that v7 will implement brand new API which would rely on TPL. So my assumption was that it will provide an interface with a method which allows to retrieve a message from a queue
var message = await _consumer.Consume(cancellationToken)
But it seems that all the TPL utilization in 7th version is mostly hidden inside or provides async methods for initialization and so on, while user code still has to subscribe to the event Received like in earlier versions of C#. It's so weird that I must be missing something. Could someone clarify that?

[lukebakken]

v7 does provide a task-based API that is mostly 1:1 compatible with the version 6.x API. If you wish to see how this code works, look at the test suite or example programs.

If you wish to use an even simpler API, I suggest looking at EasyNetQ, MassTransit, or NServiceBus. At some point those libraries will use version 7 of this one.

var message = await _consumer.Consume(cancellationToken)

If the above were in the API, how would you consume multiple messages? In a loop? I don't really see how that is an improvement over the current API, to be honest.

[Gladskih]

Yes of course in a loop. I need to handle messages one by one (FIFO) anyway - MQ is a queue after all.

Also it can be not just
Task<Message> IConsumer.Consume(CancellationToken token)

But IAsyncEnumerable<Message> IConsumer.Consume(CancellationToken token)

When current API requires to implement an event handler which should put messages into a ConcurrentQueue or a Channel just to implement the interface methods mentioned above.

[lukebakken]

It sounds like it would be useful for you to provide your suggested API as example code for end-users of this project. I would appreciate it. Feel free to open a PR with code.

[Gladskih]

I invested significant amount of time researching the options and I just want to share the knowledge for future readers here.
EasyNetQ does not support autoack flow and therefore does not support DirectReplyTo RabbitMq extension of AMQP.
MassTransit:

1. does not support Protobuf.
2. does not allow to implement a custom (de)serializer
3. does not allow to intercept deserialization exception
4. by default inflicts weird conventions (e.g. a full type name with a namespace is a contract!)
5. by default inflicts oldschool techniques like using of fault (do not confuse with dead letter queue) queue for errors instead of structured logging
6. loses priority of a message on forward
7. expects MessageId and CorrelationId to be a Guid rather than just aт arbitrary string (as in AMQP)
8. loses replyTo header on forward
9. by default expects and produces "envelop" rather than just data you interested in
10. if envelop is not used (which obviously the case when your client is not Masstransit-based) expects special header to support Direc ReplyTo feature.

Summarizing this I wish there would have been someone to give me an advice: do NOT even think about Masstransit because it's total waste of time and horrible amount of efforts for very basic scenarios (except some specific thoroughly cross cutting Masstransit native multicomponent systems).

[lukebakken]

@Gladskih this discussion isn't the appropriate place for you to post this comment. If you have found legitimate bugs in these projects then politely file issues, with code to reproduce them, in the project's repository.

If you feel like you've wasted your time, well, that's your opinion. MassTransit is a very popular software project and is used by many people who PAY for RabbitMQ support to ensure that RabbitMQ and its associated software ecosystem can continue.

Also, please note that the MassTransit maintainers have been polite and responsive to your questions and requests -

• Forwarding misses message priority MassTransit/MassTransit#5325
• How to make Masstransit to send a RabbitMQ message with arbitrary MessageId or CorrealtionId properties? MassTransit/MassTransit#5341

It's best to not alienate people who give you software for free.

[michaelklishin]

@Gladskih I have invested a very insignificant amount of time reading your comment and concluded that it was extremely disrespectful towards the maintainers of MassTransit 🤦 I would rather not see this kind of attitude towards open source software maintainers in our community.

If you don't like a tool or it does not fit your needs, just move on. No one in the open source community owes you anything. Your open source contributions track record on GitHub suggests you have no idea how thankless a job it is.